Как далеко дойти до нормализации?

Денормализация имеет преимущество быстрых SELECTs на больших запросах.

Недостатки:

• Для обеспечения целостности требуется больше кода и времени (что наиболее важно в вашем случае)

• Это медленнее в DML (INSERT / UPDATE / DELETE)

• Занимает больше места

Что касается оптимизации, вы можете оптимизировать либо для более быстрого запроса, либо для более быстрого DML (как правило, эти два являются антагонистами).

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

В случае индексов RDBMS сделает это за вас, но в случае денормализации вы нужно самому запрограммировать. Что, если Department перейдет к другому Office? Вам нужно будет исправить это в трех таблицах вместо одной.

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

Нормализуйте, пока не станет больно, затем денормализуйте, пока не заработает.

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

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

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

Кроме того, как упоминал Джон, если вам действительно понадобятся денормализованные данные (для скорости / отчетности и т. Д.), Создайте их в отдельной таблице, сохранив необработанные данные.

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

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

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

Лучше сохранить эту схему в третьей нормальной форме и позволить администратору баз данных жаловаться на стоимость соединений.

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

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

Вы не должны смотреть на денормализацию, пока не попробуете все остальное.

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

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

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

Что делать, если отдел занимает два офиса?

Что, если сотрудник номинально принадлежит к одному отделу, но работает в другом офисе (при условии, что вы имеете в виду физические офисы)?

Если вы используете целые числа (или BIGINT) в качестве идентификатора, и они являются кластеризованным первичным ключом, все будет в порядке.

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

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

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

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

Не денормализируйте.

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

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

Есть и другие наборы принципов проектирования. Они приводят к тому, что дизайн таблиц не полностью нормализован. Но это не «денормализация». Это просто другой дизайн, несколько несовместимый с нормализацией.

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

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

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

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

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

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

Нормализация - это качественное решение.

Денормализация - это решение проблемы производительности.

Вот почему -

Нормализовать до боли; Отмените нормализацию, пока он не сработает.

Качественные решения говорят о том, какая наименее нормальная форма, с которой вы можете жить:

1. Насколько важно для ваших таблиц отсутствие избыточности?
2. Насколько быстро вы хотите управлять данными?
3. Насколько ясна связь между вашими таблицами?

Решения о производительности определяют, какая наивысшая допустимая нормальная форма:

1. Достаточно ли быстро реагирует моя база данных?
2. Слишком много объединений вызывают замедление?

Когда вы установили наименьшую и высшую нормальную форму, приемлемую для вашего случая, выберите нормальную форму где-нибудь между ними.