Разрабатывая базу данных, вы должны определить первичный ключ или внешний ключ в каждой таблице базы данных?

Question

При разработке базы данных нужно приложить все усилия, чтобы определить первичный ключ или forign-ключ в каждой таблице базы данных, если в это время есть таблицы, которые не содержат уникальных полей, как мы можем связать таблицу с другой таблицей. Предположим, у меня есть три табе.

table1 Сведения о персонале

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

Таблица2 Professiona_Detail

Total_Experiance
Annual_Salary
Functional_Area
Current_Industry
Key_Skill
Resume_HeadLine

Таблица3 WorkPreference

Specify Your Preference
Start Working
Prefered Location
Job Type

В приведенной Таблице1 содержится PK, но в Таблице 2 или Таблице 3 нет Pk или FK, тогда как можно соединить эти три таблицы.

Answer 1

Table2 и Table3 должны иметь значения от FK до Table1. В противном случае вы не будете знать, для кого предназначены записи в этих таблицах. Для каждой таблицы также должно быть определено PK. Это сделано для того, чтобы вы могли однозначно идентифицировать строку при выполнении UPDATES или DELETES.

Answer 2

Нет. Это не обязательно. Но ВЫСОКО рекомендуется!

Какой-то гуру SQL однажды сказал:

Если у него нет первичного ключа, это не таблица!

Живи этим утверждением!

А внешние ключи сделают вашу базу данных более защищенной и позволят избежать появления строк "зомби". Опять же: это не обязательно или технически не обязательно во всех отношениях, но вы попадете в беду, если не будете знать об этом с самого начала! Поверь мне .... был там, вычистил этот беспорядок ......

Answer 3

Когда Разрабатывает моделирование базы данных, тогда требуется определиться с первичным ключом или внешним ключом в каждой таблице базы данных, если в то время в таблицах, которые не содержат какого-либо уникального поля, как мы можем подключить стол с другой таблицей.

(1) Да.

Вы испытываете осложнения и трудности на шаге 6, потому что вы не выполнили шаг 5. Шаги должны выполняться последовательно.

Реляционная база данных требует, чтобы строки (не столбец идентификаторов) в каждой таблице были уникальными. Это обязательно. Если строки не уникальны, это не реляционная таблица, это нечто другое, ведро с рыбой.

После этого ФК и т. Д. Будет легко. до этого ФК и т. д. будут невозможны.

(2) У вас уже есть очень хороший, стабильный уникальный идентификатор для Person. В таблицах Professional и WorkPreference отсутствует столбец или два. Они не сидят сами по себе. К кому или к чему относятся Professional и WorkPreference?

Они принадлежат Person. Единственный Person идентификатор, который у вас есть, это EmailAddress. Поэтому EmailAddress необходимо добавить к Professional и WorkPreference.

EmailAddress - это PK в Professional и WorkPreference.

EmailAddress также FK в Professional и WorkPreference до Person. (На сегодняшний день количество элементов составляет 1 :: 1.)

(3) Теперь вам также может понадобиться уникальное ограничение на Person.Name, но тогда вам придется иметь дело с двумя «Бобом Смитом» и «Бобом Смитом» против «Смита, Боба» и «Роберта Смита». Так что еще есть над чем поработать. Если это простая база данных, это может не иметь значения Person.Name может быть достаточно хорошим.

Вот и все, задача выполнена на логическом уровне.

(4) Теперь на физическом уровне (элементы, которые пользователь не видит), вы можете решить, что перенос CHAR (30) EmailAddress в дочерние таблицы нецелесообразен по соображениям производительности, поэтому вы можете добавьте узкий суррогатный ключ к Person, например PersonId INT. Суррогатный ключ - это всегда дополнительный столбец и индекс ; это не замена естественных ключей; вам все еще нужен EmailAddress UNIQUE в качестве естественного ключа, который поддерживает уникальность строк.

Тогда вы можете использовать PersonId в качестве PK в Person.

Затем вы переносите PersonId как FK и PK на Professional и WorkPreference; вместо EmailAddress.

Но вы не можете отказаться от Person.EmailAddress UNIQUE, потому что это является основой поддержания уникальных строк в Person.

Answer 4

Нет ничего, что обеспечило бы применение первичных / внешних ключей, кроме вас как разработчика.

Они не обязательны , но являются лучшей практикой и должны бытьсоздано.