Проектирование базы данных

Question

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

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

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

Всегда ценю ввод.

- S

Answer 1

Обычный совет для проектирования баз данных OLTP: нормализуйте до 3NF .

Принимая во внимание, что передовой практикой для базы данных DataWarehouse или OLAP является денормализация в Таблица фактов и вспомогательные таблицы измерений ( звездная схема ).

Так что это зависит от вашего точного использования scanario.Из вашего описания звучит так, будто у вас есть что-то ближе к OLAP.

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

Индексированные представления SQL Server может помочь вам, если в ваших отчетах используется большое количество агрегатов, и вам следует создать индексы, чтобы попытаться покрыть рабочую нагрузку вашего запроса.

• Рекомендации по индексированию SQL Server 2008

• Расширение хранилища данных с помощью SQL Server 2008

Answer 2

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

У большинства приложений, которые мне приходилось переписывать, были проблемы из-за плохо спроектированной БД.

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

Answer 3

Преимущества для нормализации:

1. экономия дискового пространства
2. меньше избыточных данных означает, что с большей вероятностью будут иметь согласованные данные
3. проще внедрять изменения в схему и /или данные при необходимости

Преимущества отмены нормализации

1. упрощенных запросов SQL (не требуется тонна объединений)
2. объединения являются дорогостоящими (медленно), и с нормализованной базой данных у вас действительно должны быть индексы на всех полях соединения (не то, чтобы индексы - это тонна работы)

Answer 4

Пятая нормальная форма (5NF) является основой наиболее хорошего дизайна базы данных, и к этому следует стремиться, за исключением случаев, когда вы находите исключительные причины не слишком.Единственное потенциальное преимущество 3NF заключается в том, что он сохраняет некоторые зависимости, которых нет у 5NF.В этих (как правило, редких) случаях вам необходимо решить, стоит ли сохранять зависимость или лучше все равно нормализовать и усилить зависимость с помощью дополнительных ограничений и бизнес-логики.

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

Answer 5

I всегда дизайн до 3NF (и призываю других).Если вы столкнетесь с конкретными проблемами производительности, вы сможете (и только затем) выяснить преимущества возврата к ненормализованным данным.Вы не возвращаетесь только ради возврата, поскольку это создает свой собственный набор проблем.

Смысл в нормализации данных состоит в том, чтобы избежать несоответствий в данных.Вы можете вернуться к производительности, но тогда вам обычно приходится вводить «хитрости» (например, триггеры) для обеспечения согласованности данных (C - ACID).