Как далеко продвинуться нормализации?

Question

У меня есть эти таблицы:

Projects(projectID, CreatedByID)
Employees(empID,depID)
Departments(depID,OfficeID)
Offices(officeID)

CreatedByID - это внешний ключ для Employees. У меня есть запрос, который выполняется почти для каждой загрузки страницы.

Плохо ли просто добавлять избыточный столбец OfficeID в Projects, чтобы исключить три объединения? Или я должен сделать следующее:

SELECT * 
FROM Projects P
JOIN Employees E   ON P.CreatedBY = E.EmpID
JOIN Departments D ON E.DepID = D.DepID
JOIN Offices O     ON D.officeID = O.officeID
WHERE O.officeID = @SomeOfficeID

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

Answer 1

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

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

Вот почему сказано -

Нормализуй до боли, Денормализуй до работы.

---

Следующие решения по качеству сообщают, какая наименее нормальная форма, с которой вы можете жить:

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

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

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

После того, как вы установили наименьшую и наивысшую Нормальную форму, приемлемую в вашем случае, выберите Нормальную форму в любом месте между

Answer 2

Не денормализовать.

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

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

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

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

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

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

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

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

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

Answer 3

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

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