Должен ли я нормализовать или добавить FK в каждую таблицу

Question

У меня возникли сомнения относительно дизайна базы данных, используемого в проекте, над которым я работаю. У меня три таблицы: Event, ProductEvents и Product. ProductEvents - таблица ссылок между Event и Product. Оба Event и Product имеют одинаковый внешний ключ.

Для удаления записей в таблице ProductEvents у меня нет внешнего ключа до Estate и поэтому необходимо удалить его перед удалением. Теперь интересно, какое лучшее решение: либо добавить внешний ключ, либо присоединиться к таблице Event или Product для каждого запроса, который необходимо выполнить.

Принимая во внимание нормы нормировки, я должен только рассмотреть вариант объединения. Однако для этой проблемы есть и предыстория. У нас есть другие таблицы, например. House и Interior, где Interior имеет FK до House. House имеет дискриминатор до Estate и содержит приблизительные 10 миллионов записей. Interior содержит пару 100 миллионов записей. Только недавно мы были вынуждены добавить дискриминатор в таблицу Interior, потому что соединения становились слишком тяжелыми и медленными, даже когда мы убедились, что набор результатов остался как можно меньше.

Какая у вас лучшая/распространенная практика для этой проблемы? Лучше ли иметь общий дискриминатор в каждой таблице или придерживаться объединений?

Answer 1

Вы можете создать свою базу данных на основе природных ключей или технических идентификаторов. С последним вы получаете (первичный ключ выделен жирным шрифтом):

• Estate (estate_id, estate_no, имя ...)
• продукт (PRODUCT_ID, product_no, estate_id, имя, ...)
• Event (event_id, EVENT_CODE, estate_id, имя, ...)
• ProductEvents (productevents_id, product_id, event_id, ...)

Здесь же с естественными ключами:

• Estate (estate_no, имя ...)
• продукта (estate_no, product_no, имя, ...)
• событий (estate_no, event_code, название, ...)
• ProductEvents (property_no, product_no, event_code, ...)

Да, при работе с техническими идентификаторами вам необходимо присоединиться, если вы хотите получить доступ к ProductEvents для определенной недвижимости.Это показывает как сильные и слабые стороны технического ID-дизайна:

1. pro: Естественный ключ находится в одном месте. Если вы решите использовать номер объекта «AX123» вместо «AE123», измените его в одном месте, и все будет готово.
2. pro: Изменения в структуре данных просты. Если событие больше не принадлежит имуществу, а теперь группе недвижимости, это незначительное изменение по сравнению с изменениями, необходимыми для базы данных на основе естественного ключа.
3. con: Доступ к данным часто включает в себя множество таблиц, чтобы получить от заданных натуральных ключей необходимые технические данные.
4. con: Конфигурация данных не может быть гарантирована dbms.

Что касается последнего пункта: хотя база данных нормализована (например, это относится к обоим моделям кстати), при проектировании ID можно использовать ProductEvents, ссылаясь на два разных состояния (один через Event, другой через Продукт). СУБД не может гарантировать, что только продукты и события для одного и того же имущества могут быть объединены в ProductEvents. С естественными ключами он может, потому что ProductEvents имеет внешние ключи для Event (estate_no, event_code) и Product (property_no, product_no), и в ProductEvents есть только одно свойство property_no.

Работая с обоими, я предпочитаю дизайн естественного ключа для больших баз данных. Однако можно даже смешивать оба. И да, вы даже можете добавить property_id в ProductEvents. Он больше не является чистым дизайном ID, но помогает быстрее получать данные, и вы можете добавлять внешние ключи к Event (event_id, property_id) и Product (product_id, property_id) для улучшения проверки согласованности данных. Я бы даже не подумал об этом ненормированном (но я могу ошибаться в этом).