Нормализация базы данных

Question

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

Но есть одно исключение из этого. Эти таблицы взяты из базы данных продуктов, в которой хранится информация (как вы уже догадались) о продуктах, которые продает компания. Я разделил большую часть информации на две таблицы: ProductBase и ProductBasePackaging.

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

ProductBase содержит довольно общую информацию, такую ​​как MarketingCopy, Keywords и т. Д., А также информацию о конструкции, т.е. материал, компоненты и т. Д.

И ProductBasePackaging, конечно, содержит данные об упаковке.

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

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

Извините, я знаю, что было много читать, я надеюсь, что это имело смысл, и спасибо всем, кто прошел через это!

Answer 1

Нормализация может выглядеть как боль в а ** прямо сейчас - но поверьте мне, в конечном счете, вы будете рад вы сделали это!Ненормализованные "плоские" таблицы со всем, кроме кухонной раковины в них, со временем станут очень неуправляемыми, возникнут несоответствия данных, и, прежде чем вы это узнаете, у вас будет огромная куча дерьма - ошибочных - данных, которые небольше не имеет никакого смысла!

Да, объединение таблиц может быть немного трудоемким, но особенно для отображения данных, вам определенно следует проверить просмотров , которые могут помочь вам написать эти СОЕДИНЕНИЯ один раз, а затемпросто используйте их как «виртуальные таблицы», которые снова содержат все.

Нормализация базы данных - примерно до 3NF - это хорошая вещь (TM) точно!Я всегда рекомендовал бы делать это, а затем, возможно, в этот момент возвращать некоторую ограниченную ненормализацию, где потребности в производительности могут потребовать этого - но только очень контролируемым образом, и с вашим полным пониманием и знанием, что вы на самом деле снова денормализуете что-то.

Answer 2

Ответ зависит .

Это зависит от того, что вы обычно запрашиваете, как вы обычно запрашиваете, как часто вы запрашиваете, насколько велика таблица для хранения всех данных .... и т. Д. Это зависит.
Примером, когда вы можете не хотеть нормализовать, может быть, если вам нужно регулярно запрашивать агрегированные или производные данные и процесс их компиляции занимает «много времени». Обычно хотя я думаю, что данные должны быть нормализованы.

Как говорится, я не уверен, что вы описали "Нормализацию" настолько, насколько это разделение. Нормализация будет включать удаление дублированных данных в разных столбцах.

Давайте возьмем ваш пример упаковки ... Мне кажется, что вы сделали запись в каком-то ProductBasePackaging, который связан PartNumber с ProductBase или чем-то.

В действительности, если бы вы нормализовали данные ... у вас была бы строка ProductBasePackaging только для каждого типа упаковки ... как, возможно, вы отправляете 1000 различных продуктов, но используете только 10 различных типов коробок. ProductBasePackaging будет иметь 10 строк, каждая из которых содержит информацию об уникальном блоке ... тогда ProductBase будет ссылаться на свой обязательный блок на PackagingID