Здравствуйте.

Собственно, такой вопрос: насколько оправдан отход от канонических нормальных форм при проектировании БД?
У нас сейчас в конторе идет живое обсуждение нового проекта и есть два лагеря: считающие, что все таблицы должны быть в 3NF, и те, кто говорит, что с введением дублирования будет получен существенный выигрыш в скорости работы, поэтому можно отойти от классики.

Каковы ваши соображения?

Особенно интересует мнение людей с большим опытом работы в области БД.

ЗЫ. Проект связан с веб.

Hello, !

> Здравствуйте.

> Собственно, такой вопрос: насколько оправдан отход от канонических
> нормальных форм при проектировании БД? У нас сейчас в конторе идет живое
> обсуждение нового проекта и есть два лагеря: считающие, что все таблицы
> должны быть в 3NF, и те, кто говорит, что с введением дублирования будет
> получен существенный выигрыш в скорости работы, поэтому можно отойти от
> классики.

> Каковы ваши соображения?

ИМХО однозначного ответа на этот вопрос не существует. С одной стороны скорость с другой семантическая раздробленность — надо искать баланс.

WBR, Igor Evgrafov.

Здравствуйте, GarryIV, Вы писали:

GIV>ИМХО однозначного ответа на этот вопрос не существует. С одной стороны скорость с другой семантическая раздробленность — надо искать баланс.

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

Hello, !

GIV>> ИМХО однозначного ответа на этот вопрос не существует. С одной
GIV>> стороны скорость с другой семантическая раздробленность — надо искать
GIV>> баланс.

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

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

WBR, Igor Evgrafov.

Здравствуйте, Аноним, Вы писали:

А>Собственно, такой вопрос: насколько оправдан отход от канонических нормальных форм при проектировании БД?
А>У нас сейчас в конторе идет живое обсуждение нового проекта и есть два лагеря: считающие, что все таблицы должны быть в 3NF, и те, кто говорит, что с введением дублирования будет получен существенный выигрыш в скорости работы, поэтому можно отойти от классики.
...
А>ЗЫ. Проект связан с веб.

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

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.

А>Собственно, такой вопрос: насколько оправдан отход от канонических нормальных форм при проектировании БД?
А>У нас сейчас в конторе идет живое обсуждение нового проекта и есть два лагеря: считающие, что все таблицы должны быть в 3NF, и те, кто говорит, что с введением дублирования будет получен существенный выигрыш в скорости работы, поэтому можно отойти от классики.

А>Каковы ваши соображения?

А>Особенно интересует мнение людей с большим опытом работы в области БД.

А>ЗЫ. Проект связан с веб.

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

Здравствуйте, <Аноним>, Вы писали:
А>Каковы ваши соображения?
Соображения — очень простые. Premature optimization is the root of all evil. В переводе на SQL это означает — проектируйте все как минимум в 3NF. Денормализацию добавляйте по мере обнаружения проблем с быстродействием. При этом четко следите за тем, чтобы денормализация не затронула семантику. В идеале, ее вообще не должно быть видно из клиентского приложения.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте.

А>Собственно, такой вопрос: насколько оправдан отход от канонических нормальных форм при проектировании БД?
А>У нас сейчас в конторе идет живое обсуждение нового проекта и есть два лагеря: считающие, что все таблицы должны быть в 3NF, и те, кто говорит, что с введением дублирования будет получен существенный выигрыш в скорости работы, поэтому можно отойти от классики.

А>Каковы ваши соображения?

А>Особенно интересует мнение людей с большим опытом работы в области БД.

А>ЗЫ. Проект связан с веб.

Как показала практика: пока не тормозит — не денормализуй. У нас проект на Оракле, денормализовать пришлось когда количество документов в небольших базах стало более 200тыс и пользователи начали слишком интенсивно делать отчеты. Если у тебя в базе таблиц более чем на 100000 строк нету, то о денормализации даже и не думай — заколебешься синхронизовать таблички. Впрочем, если разработку ведешь ты один и можешь гарантировать что все всегда совпадает — мой совет силы не имеет

Здравствуйте, Аноним, Вы писали:

А>Собственно, такой вопрос: насколько оправдан отход от канонических нормальных форм при проектировании БД?
Оправдан, но в очень редких экзотических случаях. Чаще всего отход от NF происходит вследствии лени либо оргбардака.
Кстати, существенного выигрыша в скорости отход от 3NF не даёт.

ИМХО, оптимальной будет такая стратегия (при которой и волки целы, и овцы сыты). База логически разбивается на две области:
1. Данные, вводимые пользователями. Здесь можно и нужно применять нормализацию. Резон — не дать пользователю даже принципиальной возможности ввести противоречивые данные.
2. Служебные данные, выжимаемые автоматикой из основных (итоги-подитоги, срезы актуальных данных,...) и служащие для снятия с ручника. Важно добиться того, чтобы служебные данные либо в принципе не могли сломаться, либо в случае чего могли быть удалены и перегенерированы на базе пользовательских данных. Кстати, именно так и именно для этих целей работают индексы, материализованные вьюхи и олаповские кубы.

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

Есть, конечно ещё один фактор против нормализации. Когда база состоит из множества табличек, к ней сложнее приделывать программный интерфейс. Проще всего общаться с 1NF

Здравствуйте, Аноним, Вы писали:

В дополнение к предыдущим правильным ответам, я бы отметил пару факторов.

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

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

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