Est-ce un concept de base de données OK?

Question

EDIT1: J'ai essayé d'effacer la question en renommant les tables ET leurs relations. EDIT2: S'il vous plaît ne regardez pas le TYPE de données que je tiens dans les trois tables DB. Ils ont été fabriqués à la volée. Ce ne sont pas mes scénarios du monde réel (et non, je ne peux pas parler de mes données du monde réel .. en fait c'est 1 parent et 6 enfants, actuellement). S'il vous plaît juste ignorer quel type de données et juste regarder le fait que certaines données sont nécessaires. EDIT3: Les deux FK sont une relation 0 ou 1 à 1. PAS de 0 à plusieurs. Pas 1 à 1. J'essaie d'éviter la relation 0 ou 1 à 1 à une relation 1 à 1, donc je n'ai pas besoin d'avoir des JOINTS EXTÉRIEURS, mais plutôt avoir une INNER JOIN.

Question: Je dois savoir si la conception de base de données proposée est bonne/mauvaise/lame/etc ..

Problème: aujourd'hui j'ai essayé de faire une vue indexée , mais a échoué « parce que mes tables ont extérieur joint. Soupir. Donc je me demandais si je peux refixer cette conception pour être comme la conception suivante:

• Trois tables.
• table_User a une FK sur table_Address
• table_User a une FK sur table_Vehicle
• etc ..

et le tableau B et C (qui agissent sorta comme des tables de recherche maintenant) ont ..

• Id INT IDENTITY PK
• description de NVARCHAR (100) NULLABLE

Notez le nullable? De cette façon, quelque chose dans table_User n'existe pas dans table_Address ... le champ est null (à cause de la jointure interne). Avant, je faisais un LEFT OUTER JOIN, donc s'il n'y avait pas de données dans table_b, j'obtiendrais des nulls pour chaque champ.

Je vais jeter quelques exemples de données ici ...

Table_User

• ID: 1, Nom: Fred, AddressID: 1 (NULL)
• ID: 2, Nom: Joe , AddressID: 2 (1 smith rue .....)
• ID: 3, Nom: Jane, AddressID: 2 (1 rue Smith .....)

Table_Address

• ID: 1, Description = NULL
• ID: 2, Description = 1 smith rue

etc.

Alors je peux enfin mettre tout cela dans une vue indexée. (Mon scénario de la vie réelle a environ 8 tables).

REMARQUE: DB est Microsoft Sql Server 2008, mais cela peut s'appliquer à n'importe quelle base de données.

Q1: Ce design semble-t-il correct? Q2: Donc ce que je fais ici, c'est que je normalise les données, n'est-ce pas? en gardant les jointures intérieures ensemble. Q3: Enfin, si c'est une bonne façon de procéder .. puis-je également m'assurer que les données dans les tableaux sont uniques (par exemple les adresses) en ayant des contraintes uniques ou des clés ou des index ou quoi (i je ne suis pas sûr de la terminologie appropriée).

merci les gourous!

Answer 1

Je trouve votre question confuse, mais peut-être que je peux vous aider un peu. Tout d'abord, les tables n'ont pas de jointures, les requêtes ont. Vous ne créez pas de table avec une jointure à une autre table. Il y a seulement 2 tables qui peuvent être liées, et vous pouvez interroger ces tables en utilisant des jointures.

Je vous recommande de lire à propos de la normalisation db. Wikipedia a un bon article: http://en.wikipedia.org/wiki/Database_normalization

À propos de votre cas actuel, je ne suis pas sûr de ce que vous essayez de faire. Avoir un identifiant pour une adresse semble correct si cette adresse est répétée dans différentes lignes. Cependant, avoir besoin de plusieurs "tables d'adresses" semble bizarre. Les choses les plus importantes à retenir lors de la conception sont: - Avoir une clé primaire correcte dans chaque table, de sorte que vous pouvez joindre correctement les tables. - Ne répétez pas les données sauf si vous avez une très bonne raison. Mais je recommande à nouveau l'article précédent.

espérons que cela aide! :)

Answer 2

Une question très confuse, alors s'il vous plaît chercher la normalisation des bases de données. La 3ème forme normale (j'espère qu'on l'appelle comme ça en anglais) devrait résoudre la plupart des problèmes.

Conseil rapide: si vous avez des données répétées, vous avez besoin d'un tableau séparé auquel vous faites référence dans le premier via une clé étrangère. Tout le reste est juste des questions.

Answer 3

Vous ajoutez donc essentiellement des enregistrements faux dans les tables B et C afin d'avoir le même nombre de lignes que dans A? Je ne le ferais pas si j'étais vous, car si votre jeu de données est grand, alors vous augmentez le nombre de lignes sans réel besoin et vous courez le risque d'une incohérence (votre disposition dépend fortement de votre capacité à avoir ces faux enregistrements insérés). En dehors de cela, que voulez-vous réaliser avec une vue indexée? Gain de performance? Vous n'écrivez pas quel SGBD vous utilisez, mais d'après mon expérience dans MSSQL cela ne vous donnera pas beaucoup de gain, car à condition d'avoir les index appropriés dans les tables A, B et C, le serveur pourra utiliser eux pour construire un bon plan de requête même sans une vue indexée.

Answer 4

Personnellement, je dirais «non» à cette conception. Motifs:

• (peut ne pas s'appliquer) Si vous essayez de conserver le champ d'adresse normalisé, vous devez traiter ce champ pour vous assurer d'éviter les doublons non souhaités. C'est à dire. vous devez vous assurer que l'utilisateur entre l'adresse dans le format correct (sinon '1 mystreet' pourrait également être entré comme '1, mystreet' ou autre - besoin de vérifier ceci pour éviter les doublons, sinon la normalisation n'est bonne)
• Même si vous trouvez une raison de normaliser (c'est-à-dire garder un tableau séparé pour l'adresse), le concept d'adresse «factices» me semble étrange.Pourquoi ne pas utiliser une relation FK Nullable, c'est-à-dire stocker un ID d'adresse NULL dans la table des utilisateurs parente, au lieu de simplement y placer un ID fictif.