База данных: должны ли таблицы всегда быть нормализованы и иметь первичные ключи?

Question

У меня есть база данных, хранящая запросы клиентов о продуктах.

Ссылка на запрос (текст), номер продукта (int) и номер редакции (int) вместе однозначно определяют одно обсуждение между продажами и клиентом.

В результате имеется много таблиц, каждая из которых содержит конкретную информацию об одном запросе, обычно идентифицируемую как объединенные значения enq, pdt и rev.

CREATE TABLE не использует какой-либо уникальный ключевой ключ AUTO INCREMENT UNIQUE.

Мой вопрос: приемлем ли этот дизайн базы данных? Должны ли таблицы всегда быть нормализованы?

Спасибо за совет.

Answer 1

Лично у меня ВСЕГДА всегда есть какой-то первичный ключ во всех таблицах, даже если это номер автоинкремента, используемый ни для чего другого

Что касается нормализации, я думаю, что нужно стремиться к нормализованным таблицамно в действительности есть много веских причин, когда дизайн стола хорош, но не нормализован.Именно здесь «теория» проектирования БД встречается с реальностью - но хорошо знать, что такое нормализация, стремиться к ней и иметь веские причины, когда вы отклоняетесь от правил (а не просто игнорируете правила илихуже, игнорируя хорошие правила дизайна).

Answer 2

Нет необходимости использовать AUTOINCREMENT, но каждая таблица должна иметь какой-то ПЕРВИЧНЫЙ КЛЮЧ.Первичный ключ может быть комбинацией нескольких полей, которые вместе идентифицируют запись однозначно.

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

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

Answer 3

Наличие PRIMARY KEY (или ограничения UNIQUE), во-первых, гарантирует, что эти значения действительно уникальны, и, во-вторых, значительно улучшит поиск по данному запросу.

A PRIMARY KEY подразумевает создание индекса более (enq, pdt, rev), и этот запрос:

SELECT  *
FROM    enquiries
WHERE   enq = 'enquiry'
        AND pdt = 'product'
        AND rev = 'revision'

завершится в одном поиске по индексу.

Без индекса этот запрос потребует сканирования всей таблицы, и нет никакой гарантии, что вы не получите дубликаты.

Если только для очень, очень, очень особых условий (например, сильно загруженных журнальных таблиц) у вас всегда должно быть PRIMARY KEY в ваших таблицах.

Answer 4

В теории нормализации нет ничего, что касалось бы того, должен ли стол иметь простой или составной первичный ключ. Хотите верьте, хотите нет, но понятие «первичный ключ» не является компонентом реляционной модели данных.

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

Если таблица не имеет объявленного первичного ключа, она может содержать дублирующиеся строки. Таблица с дублирующимися рядами представляет собой набор кортежей, а не набор кортежей. Если вы имеете дело с сумками, а не с наборами, результаты, предсказанные реляционной моделью, могут не применяться. Вот почему так важно предотвращать повторяющиеся строки.

Answer 5

Я откололся от стада на этом. НЕ делайте ссылку на запрос (текст), номер продукта (int) и номер редакции (int) первичным ключом. Вы указали, что ссылка на запрос относится к текстовому типу, и имели в виду, что она будет иметь ширину 25, 50 или 500 символов? Если первичный ключ сделан из этих полей, он будет слишком широким, на мой взгляд, так как он будет добавлен к каждому индексу, созданному для этой таблицы, увеличивая размер каждой строки индекса на размер трех полей и любой таблицы, которую необходимо использовать. внешнему ключу обратно в эту таблицу также понадобятся три поля.

Сделайте три поля уникальным индексом. Поместите значение автоинкремента как первичный ключ и сделайте его кластеризованным индексом. Таблицы, которые будут ссылаться на эту основную таблицу, будут иметь небольшой объем памяти, чтобы связать данные из первой таблицы в другую.

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

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

Answer 6

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