2010-10-23 5 views
2

Si une table parent et une table enfant sont remplies de données, est-il trivial d'ajouter une nouvelle table entre elles?Présentation d'une nouvelle table entre les tables parent et enfant

Par exemple, avant l'introduction de la relation:

Parent -> Enfant

Puis:

Parent -> Nouvelle table -> Enfant

Dans ce cas, je fais référence SQLite3 donc un enfant dans ce schéma a une clé étrangère qui correspond à la clé primaire de la table parent.

Merci!

Répondre

2

Cela peut être trop évident, mais ...

triviale, il est dépendra de la façon dont beaucoup de code a déjà été écrit qui doit changer avec cela. Si c'est une nouvelle application, avec peu de code écrit, et que vous commencez juste à travailler sur le design, alors oui c'est trivial. Si vous avez des tonnes de fonctions (que ce soit du code externe, ou du code DB comme des procédures stockées et des vues) accéder à ces tables en attendant la relation d'origine, alors cela devient moins trivial.

Le changement dans la base de données devrait être relativement non-trivial, en supposant que vous connaissiez assez de SQL pour peupler la nouvelle table et mettre en place les relations.

Comme pour tous les défis de développement, il vous suffit de regarder ce qui sera affecté, comment et comment vous allez comptabiliser ces changements.

Tout cela est une façon très longue de dire «cela dépend de votre situation».

+0

merci David, oui c'est une nouvelle application mais j'ai hâte d'essayer de créer le meilleur design. Je suppose qu'il n'y a aucun moyen d'anticiper tous les besoins ou les demandes de l'application à l'avenir. Je tiens à dire à partir de CoreData parce que je voudrais que les utilisateurs puissent mettre à jour leurs données en dehors de l'application elle-même. – Boojeboy

+0

Je ne sais pas depuis combien de temps vous développez et concevez des applications, et il semble que vous êtes relativement nouveau ... Le reste est basé sur cette supposition, donc je suis désolé si je suppose que c'est faux ...Le garçon avez-vous raison de ne pas anticiper les besoins et les demandes. Cependant, à mesure que vous acquérez de l'expérience, vous apprendrez à concevoir la base de données afin de minimiser l'impact des modifications. La plupart des applications que j'ai dû réécrire à partir de zéro ont été réécrites en raison d'une mauvaise conception sous-jacente au niveau de la base de données. Alors vous êtes sur la bonne voie et pensant dans la bonne direction. Continuez! – David

0

Je ne suis pas en désaccord avec David du tout, juste être précis sur quelques aspects du changement.

Si vous avez implémenté des standards raisonnables, alors le seul code affecté avec le code qui adresse les colonnes modifiées dans Child (pas New_Table). Si ce n'est pas le cas, alors une quantité inconnue de code, qui ne devrait pas avoir besoin de changer, devra changer.

La deuxième considération est la qualité de la clé primaire chez l'enfant. Si vous avez des clés relationnelles naturelles, l'ajout de New_Table a moins d'impact, pas de modifications de données requises. Si vous avez des clés de type IDENTITY, vous devrez peut-être recharger, ou pire, "re-factoriser" les clés. Enfin, l'introduction de New_Table est une correction à une erreur de normalisation, ce qui est une bonne chose. Par conséquent, certaines colonnes Child.column deviendront New_Table.columns et New_Table peut être chargée à partir des données existantes. Vous devez faire cela correctement et complètement, afin de réaliser le gain de performance de la correction. Cela peut signifier changer quelques segments de code supplémentaires.

Si vous avez SQL ANSI, toutes les tâches sont assez simples et directes.

Questions connexes