Как Вы знаете, когда для базы данных SQL нужно больше нормализации?

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

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

См. Описание основ нормализации базы данных

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

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

Это довольно хорошая статья. Стать нормальным - это наука, а не искусство. Теперь, зная, когда проводить DE нормализовать ... это искусство.

http://www.alvechurchdata.co.uk/hints-and-tips/softnorm.html

Всякий раз, когда у вас есть реляционная база данных ....

Нет, на самом деле есть законы, посмотрите эту ссылку в Википедии .

они называются пятью нормальными формами или что-то в этом роде. Первоначально от парня, который изобрел реляционные базы данных в 50-х / 60-х годах, Э. Ф. Кодда.

«Ключ - это весь ключ и ничего, кроме Ключа, так что помоги мне, Кодд»

Это синопсис:

1. Первый нормальный форма (1НФ) Таблица верно представляет отношения и не имеет повторяющихся групп
2. Вторая нормальная форма (2NF) Нет неосновной атрибут в таблице функционально зависит от детали (собственное подмножество) ключа-кандидата
3. Третья нормальная форма (3NF) Каждые неосновной атрибут нетранзитивно зависит от каждого ключ таблицы Каждая нетривиальная функциональная зависимость в таблице - это зависимость от суперключа
4. Четвертая нормальная форма (4NF) Каждые нетривиальная многозначная зависимость в таблице - зависимость от superkey
5. Пятая нормальная форма (5NF) Каждая нетривиальная зависимость соединения в таблице подразумевается суперключами таблицы. Нормальная форма домена / ключа (DKNF) Ronald Fagin (1981) [19] Каждое ограничение таблицы является логическим следствием ограничений домена таблицы и ограничений ключа
6. Шестая нормальная форма (6NF) Таблица не имеет нетривиальные зависимости соединения вообще (со ссылкой на обобщенное соединение operator)

Когда вы начинаете сомневаться, нужно ли больше базы данных SQL нормализация.

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

Прочтите статью в Википедии о нормализации базы данных .

Обычно 3NF - это все, что вам нужно, и он следует трем правилам:

Каждый столбец в таблице должен зависеть от:

• ключа (1NF),
• всего ключа (2NF),
• и ничего, кроме ключа (3NF) (так что помогите мне, Кодд - это способ, которым обычно заканчивается цитата).

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

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

Когда вы замечаете, что вам нужно повторить одни и те же данные, или когда вы начинаете использовать отдельные поля в качестве массивов.

Я предполагаю, что вы говорите о транзакционной базе данных, поддерживающей интерактивное приложение, но чего бы это ни стоило ...

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

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

Other people have pointed you to the formal rules for normalization. Here are some informal guidelines I use:

1. If you have columns in a table the names of which differ only by a number (eg Phone1 and PHone2).

2. If you have any columns in a table that should be filled in only when another column in the table is filled in.

3. If updating a "fact" in the database (such as a street address) requires more than one UPDATE.

4. If the same question could ever get two different answers depending on which table you get your information from.

5. If the answer to any non-trivial question can be gotten from the database without JOINing at least two tables.

6. If you have any quantity-based restrictions in the database other than "only 1 of something is allowed" (that is, "only one address is allowed" is okay, but "only two addresses are allowed" indicates a normalization problem).