Какова наилучшая практика создания Первичного/Уникального Идентификатора в таблице РСУБД, если возможны и Параметры кандидата, и Компонентный ключ?

Сценарий:
- Существует два отдела, а именно «Программное обеспечение» & «Оборудование».
- У них есть такие подразделения, как «Cobol», «Fortran», «Pascal», «QBasic» в отделе программного обеспечения.
- И «ОЗУ», «Жесткий диск», «Монитор», «ЦП» в аппаратном обеспечении отдел.
- Ниже приведены форматы таблиц для отдела и Подразделение столов.Какова наилучшая практика создания Первичного/Уникального Идентификатора в таблице РСУБД, если возможны и Параметры кандидата, и Компонентный ключ?

базы данных используются: Oracle

Таблица 1: Таблица Департамент

Таблица 2: Отдел Таблица для вышеуказанных отделов (Format 1 - первичный ключ/Уникальный идентификатор столбца = Div_id)

Таблица 2: Таблица Отдел для вышеуказанных отделов (Формат 2 - Первичный ключ/уникальный идентификатор столбца = Div_id + Dep_id)

В приведенных выше двух форматов таблиц разделения, я не могу в состоянии найти профи & минусов. Таким образом, в этих форматах лучше всего создавать первичный/уникальный идентификатор. И почему это лучше?

Есть ли разница в производительности между обоими форматами при использовании запроса выбора?

источник

2017-02-19 Jeet

В составных клавиш нет ничего плохого, но в этом случае это кажется надуманным. – reaanb

Пожалуйста, используйте [текст, а не изображения/ссылки для текста (включая код, таблицы и ERD)] (https://meta.stackoverflow.com/q/285551/3404097). Используйте изображение только для удобства, чтобы дополнить текст и/или за то, что не может быть указано в тексте. – philipxy

Кандидат против композита не имеет значимого выбора. Иногда CK являются составными. Мы получаем CK, а затем выбираем PK. В вашем названии вы имеете в виду «когда возможны простые и сложные варианты CK»? Сначала приходите по столам. Затем вы определяете CK. Затем вы выбираете ПК. Учитывая каждую таблицу здесь и здравый смысл для FD, в каждой есть только один CK. Поэтому у вас нет выбора. Вы имеете в виду, какой дизайн/таблицу выбрать? Ну, как определяются подразделения в бизнесе? Ваша таблица 2, похоже, не согласна с вашим бизнесом. – philipxy

Вы можете использовать один столбец в качестве первичного ключа в формате 1 показывает или использовать комбинированный первичный ключ, как в формате 2. Для меня формат 1 является один пойти на, потому что:

каждая запись имеет собственный id, и через него можно получить доступ с помощью только одного столбца, и вы можете связать другую таблицу только с этим полем (внешний ключ)
Общая реализация базы данных для генерации идентификатора - это форма из 1, просто подсчет числа, в противном случае вам нужно сделать последовательность или код этого внутри вашего приложения.
формат 2 имеет только очарование, которое вы имеют для каждого элемента и деления номер один и т. д., но действительно заботятся о числах, если вам нужно что-то подобное, вам лучше пойти на отдельную таблицу, и если вы хотите считать, следует использовать count (*), а не getMax ;-)
, если вы хотите, чтобы выбрать все элементы из отдела 1 или 2 не делает никакой разницы

так ИМХО идти на формат 1, это самое практичное решение

источник

2017-02-19 06:59:32 matyonice

Формат 1 более простой, не по своей сути более надежный. Ваши первые две причины можно свести к тому, что «один ключ столбца проще, чем составные клавиши». В противном случае, я в основном согласен с вашим ответом. – reaanb

спасибо, что указали это, обновили ответ для большего удобства – matyonice

формат 2 близок к что бы я выбрал. Первичный ключ делает больше, чем действует как уникальный столбец. Он также может обеспечить целостность данных и помочь объяснить, что такое роль таблицы.

This article помог мне разобраться.

источник

2018-02-25 17:03:34 Abu3odeh

Какова наилучшая практика создания Первичного/Уникального Идентификатора в таблице РСУБД, если возможны и Параметры кандидата, и Компонентный ключ?

ответ

Смежные вопросы