Lors du développement de la base de données puis compolsury pour définir la clé primaire ou la clé forign dans chaque table de la base de données?

Question

Lors du développement de la base de données puis compolsury pour définir la clé primaire ou clé forign dans chaque tables de la base de données si des tables qui ne contiennent pas de champ unique cette heure comment pouvons-nous connecter la table avec autre table. Supposons que j'ai trois tabe.

table1 Personel Détail

Emai_Address (PK) 
Name 
City 
ContactNo 
Land_Line_No 
D_O_B 
Gender 
Marital_Status 
Language_Known 

Tableau 2 Professiona_Detail

Total_Experiance 
Annual_Salary 
Functional_Area 
Current_Industry 
Key_Skill 
Resume_HeadLine 

Table3 WorkPreference

Specify Your Preference 
Start Working 
Prefered Location 
Job Type 

Le obove tableau 1 contient la PK, mais Tableau2 ou le tableau 3 ne contient aucune Pk Ou FK alors comment connecter cette trois table.

Answer 1

Non. Ce n'est pas obligatoire. Mais FORTEMENT recommandé!

Certains gourou SQL a dit:

Si elle ne dispose pas d'une clé primaire, ce n'est pas une table!

Vivez par cette déclaration! Et les clés étrangères rendront votre base de données plus sécurisée, et éviteront les lignes "zombies". Encore une fois: ce n'est pas obligatoire ou techniquement nécessaire par tous les moyens, mais vous aurez des ennuis si vous ne le savez pas dès le début! Croyez-moi .... là, nettoyé ce désordre ......

Answer 2

Table2 et Table3 devrait avoir un FK à Table1. Sinon, vous ne saurez pas à quelle personne les enregistrements de ces tableaux sont destinés. Chaque table doit également avoir un PK défini pour cela. C'est ainsi que vous pouvez identifier de manière unique une ligne en faisant UPDATES ou DELETES.

Answer 3

Rien, en tant que développeur, n'appliquera les clés principales/étrangères.

Ils ne sont pas obligatoire, mais constituent la meilleure pratique et doit être créé.

Answer 4

Lorsque développement la modélisation de la base de données compolsury puis de définir la clé primaire ou forign dans chaque table du databse si des tables qui ne contiennent pas de champ unique temps comment peut-on relier la table avec autre table.

(1) Oui.

Vous rencontrez des complications et des difficultés à l'étape 6 car vous n'avez pas terminé l'étape 5. Les étapes doivent être suivies dans l'ordre. Une base de données relationnelle requiert que les lignes (et non la colonne d'identité) de chaque table soient uniques. C'est obligatoire. Si les lignes ne sont pas uniques, ce n'est pas une table relationnelle, c'est autre chose, un seau de poisson.

Après que FKs, etc sera facile. avant cela, FKs etc sera impossible.

(2) Vous avez déjà un très bon identificateur unique stable pour Person. Les tables Professional et WorkPreference manquent une colonne ou deux. Ils ne s'assoient pas seuls. À qui ou à quoi s'appliquent les codes Professional et WorkPreference? Ils appartiennent à un Person. Le seul identifiant Person que vous avez identifié est EmailAddress. Donc, EmailAddress doit être ajouté à Professional et WorkPreference.

EmailAddress est le PK dans Professional et WorkPreference.

EmailAddress est également le FK dans Professional et WorkPreference à Person. (Jusqu'à présent la cardinalité est 1 :: 1.)

(3) Maintenant, vous pouvez également avoir besoin d'une contrainte unique sur Person.Name, mais alors vous devez faire face à deux "Bob Smith" et "Bob Smith" vs "Smith , Bob "contre" Robert Smith ". Il y a donc encore du travail à faire. S'il s'agit d'une base de données simple, il se peut que cela ne soit pas important. Person.Name

Voilà, la tâche est terminée au niveau logique.

(4) Maintenant, au niveau physique (éléments que l'utilisateur ne voit pas), vous pouvez décider que portant le CHAR (30) EmailAddress dans les tableaux de l'enfant ne sont pas judicieux pour des raisons de performance, de sorte que vous pouvez ajouter une clé de substitution étroite à Person, telle que PersonId INT. Une clé de substitution est toujours une colonne et un index supplémentaires; ce n'est pas une substitution pour les clés naturelles; Vous avez toujours besoin de EmailAddress UNIQUE comme clé naturelle qui conserve l'unicité des lignes.

Ensuite, vous pouvez utiliser PersonId comme PK dans Person. Ensuite, vous migrez PersonId en tant que FK et PK vers Professional et WorkPreference; au lieu deEmailAddress.

Mais vous ne pouvez pas abandonner Person.EmailAddress UNIQUE, parce que c'est la base de maintenir des lignes uniques dans Person.