Trop de champs sur ma table mais je veux en ajouter d'autres

Question

J'ai une table dans ma base de données SQLServer 2000 qui a été mal conçue à mon avis.

Il contient un grand nombre de champs et doit être refactorisé. Cependant, jusqu'à ce que je puisse faire cela, j'ai d'autres projets en cours et l'un d'entre eux nécessite une relation avec cette table.

Je suis vraiment réticent à ajouter un autre champ à cette table pour le moment. (Il doit y avoir ~ 130) dans celui-ci mais j'ai besoin de finir cette tâche d'avance et je pense à un travail autour.

Est-ce une bonne pratique de créer une table d'extension dans ce cas? Je pense à un avec une clé étrangère à la clé primaire de la table d'origine. Devrais-je simplement ajouter le champ à la table d'origine? Est-ce que 130 champs sont ok?

Answer 1

IMO 130 champs est manière trop. Cela ressemble sûrement à une base de données mal conçue (ou un développeur paresseux: o))

Si vous allez nettoyer le désordre plus tard, personnellement, je voudrais ajouter ces champs. Mais seulement si je savais que j'avais le temps de le réparer bientôt. Ajout d'une table d'extension ressemble à un autre correctif et le début d'une autre chose à corriger dans les 3-4 ans.

Vous voudrez peut-être ajouter un tableau de paramètres plus tard - ou quelque chose de similaire. Ou déplacez les champs dans leurs propres tables plus tard, groupés par leur fonction.

Answer 2

Si vous y revenez plus tard pour le réparer, tout ira bien. Vous devez le mettre à l'écart pour le moment, n'est-ce pas?

Piratez la table d'extension, notez-la et revenez la réparer correctement lorsque vous avez le temps.

Answer 3

130 champs est quelque chose d'un accomplissement. Ecrire un poste ici quand vous frappez 200.

Je peux suggérer (mais n'insisterai pas) la division de la table en plusieurs plus petites. Groupez les champs par leur usage commun. Si une partie de la table traite des paramètres, créez-en une table de paramètres.

Une autre option consiste à grouper les champs selon la fréquence d'utilisation. Créez une petite table pour les champs les plus fréquemment consultés, et ceux qui sont moins fréquemment utilisés peuvent être déplacés vers l'autre table. Ainsi, vous améliorerez vos indicateurs de performance.

Answer 4

Vous pouvez diviser la table MAINTENANT et créer une vue avec le même nom que la vieille table, le remplaçant ainsi. L'ajout de nouveaux champs n'est pas un problème alors. Vous pouvez créer une vue indexée pour augmenter les performances lors de l'utilisation de View, mais cela augmente la demande de stockage.

plus tard lorsque vous avez le temps de, faites votre refactoring.

Answer 5

Si la table est déjà dénormalisée, c.-à-d. les 130 champs ne sont pas tous identifiés par la clé primaire, alors l'ajout d'un nouveau champ à cette table ne va pas introduire de nouveaux problèmes que vous n'avez pas déjà.

En fait, je vous suggère de le faire plutôt que d'ajouter une toute nouvelle table qui peut ou peut ne pas avoir une relation valide avec la table principale. Avant d'ajouter une nouvelle table, je voudrais essayer de ranger sérieusement le design en obtenant vos tables à la troisième forme normale. Par conséquent, ajouter simplement le champ supplémentaire est un compromis raisonnable entre faire quelque chose maintenant, et faire ensuite un refactoring approprié plus tard.

Answer 6

Fix maintenant ...

130 est à mon humble avis beaucoup, et si vous le laissez glisser, alors vous ne sera jamais le temps de le fixer plus tard (à moins qu'il soit cassé).

Maintenant, vous avez une "excuse" pour conduire une vraie solution ici. Au lieu de créer une table d'extension, essayez d'obtenir la "approbation" pour diviser la table proprement, car "une base de données dans SQL Server ne peut contenir que 8 Ko"

Answer 7

Le conseil pour le corriger maintenant est séduisant mais probablement mal placé. Ajouter une colonne à la table existante est le travail d'une demi-journée. Alors que diviser la table en plusieurs tables plus petites, construire une vue, migrer les données, les tests de régression ... c'est un gros travail - et risqué -, c'est pourquoi vous ne l'avez pas abordé auparavant.

L'application de la dernière modification sous forme de tableau distinct ajoute une complexité supplémentaire au système sans aucun bénéfice, sauf en tant que déclaration d'intention. Et, avouons-le, jusqu'à ce que la largeur de la table devienne un problème de performance ou affecte l'application d'une autre manière mesurable, l'adresser restera au bas de la liste des tâches du projet. Donc, soyez pragmatique: ajoutez la colonne à la table existante. Il s'énerve mais les alternatives sont pires.