Нормализация лучше или составной первичный ключ лучше?

Question

У меня есть таблица в БД Oracle, скажем, таблица Студента. StudentID - это первичный ключ в таблице. У меня есть еще один столбец с интересующими субъектами, скажем, имя столбца интересуется_SUB. Студент может иметь более одного заинтересованного предмета. В этом случае у меня есть следующие 2 варианта:

1) Наличие столбцов StudentID и Interested_SUB в качестве составного первичного ключа. В этом случае, например, если студент заинтересован в 3 предметах, у меня будет 3 строки в таблице с (S1, SUB1) (S1, SUB2) и (S1, SUB3) в качестве значений столбцов, а все остальные столбцы будут иметь одинаковые значения. значения для этих трех строк.

2) Иметь отдельную таблицу со столбцами StudentId и Interested_SUB и дополнительный столбец в первой таблице, чтобы указать, заинтересован ли учащийся в нескольких предметах. В этом случае я добавлю по одной строке для каждого учащегося в таблице учеников с studentId и SUB как (S1, SUB1), а также с новым столбцом индикатора как «Y». Во второй таблице (S1, SUB2) & (S1, SUB3).

Подскажите, пожалуйста, какой из перечисленных вариантов увеличивает производительность БД.

Заранее спасибо

Answer 1

Таблица ученика, как правило, содержит много значений об ученике. Как это будет выглядеть с вариантом 1? Например. Вы хотели бы видеть имя, возраст или семестр в каждом ряду? Вероятно, нет.

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

students:  
1, Mister X  
2, Mister Y

subjects:  
1, Computer science  
2, Mathematics

students_subjects:  
1, 1  // Mister X likes computer science  
1, 2  // Mister X likes mathematics, too  
2, 2  // Mister Y likes mathematics only

Вероятно, это будет не так эффективно, как запись всего в одну таблицу. Но вы не должны думать о производительности слишком рано и без причины.

Answer 2

О «успеваемости» довольно сложно судить, не имея метрик относительно того, что такое производственный сценарий (например: сколько студентов? Сколько предметов, каков ожидаемый процент студентов, имеющих более одного предмета в качестве интересов?)

С другой стороны, ваше второе решение довольно плохое с точки зрения дизайна (оно нелогично, опирается на логику, которая не сразу бросается в глаза при взгляде на схему БД, усложняется в случае, если кто-то захочет отказаться от нееего интересов ...) и даже в довольно невероятном случае, когда он более "эффективен", фактические выгоды будут значительно омрачены увеличением сложности.

Итак, в двух словах: забудьте решение № 2,

Answer 3

То, что вы описываете, является таблицей пересечений (соединением или связью АКА). Это общая конструкция для представления отношений «многие ко многим». У вас есть таблица STUDENTS с общей информацией о студентах (имя, дата рождения и т. Д.) И таблица SUBJECTS с общей информацией о предметах (имя, учитель и т. Д.). Вам нужна таблица STUDENT_SUBJECTS, чтобы показать, какие студенты интересуются какими предметами.

Что касается ключей, то здесь нет жестких и быстрых правил. Теория предпочитает составной естественный ключ (STUDENT_ID, SUBJECT_ID). Это был бы мой выбор, если бы не было других столбцов или данных, связанных с таблицей. Тем не менее, не исключено, что другие данные могут зависеть от STUDENT_SUBJECTS - например, ASSIGNMENTS, TESTS и т. Д. В этом случае синтетический первичный ключ (STUDENT_SUBJECT_ID) намного более управляем, когда распространяется как внешний ключ. Тем не менее, крайне важно продолжать применять естественный ключ с помощью уникального ограничения.

Answer 4

На вопросы, связанные с производительностью базы данных, невозможно ответить, не зная лот подробнее о ситуации:

• Насколько большой будет таблица?
• До скольких предметов может учиться студент?(«Больше чем один» может означать пять или сотню)
• Сколько столбцов будет повторяться?
• Какие типы запросов вы будете выполнять?
• Какие индексы у вас есть в таблицах?

И даже это просто царапает поверхность;вам все равно нужно проверить , чтобы иметь возможность сказать что-либо окончательно.

В общем, нормализованный - это «более чистый» вариант, который упрощает и облегчает все вокруг;но де-нормализация часто может ускорить процесс.Я бы пошел с нормализованным, если вам абсолютно не нужно дополнительная производительность.

Answer 5

В реальных базах данных для больших таблиц чем проще ключ, тем лучше. Это делает сканирование и объединение намного быстрее и потребляет меньше оперативной памяти. Искусственный цифровой ключ может быть быстрее и более масштабируемым, чем не числовой и / или составной.

В вашем случае обязательно идите на нормализацию. Это будет не только быстрее (меньше строк), но и лучше отображать домен и будет менее хрупким (не нужно беспокоиться о синхронизации нескольких строк для одного учащегося).