Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Насколько действительно полезна нормализация? / 25 сообщений из 68, страница 1 из 3
  1  все
27.04.2005, 21:42
    #33039392
DarkBoatman
DarkBoatman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Здравствуй, All!
На тему нормализации исписаны горы бумаги электронного текста. Но возник спор, в котором некие люди утверждают, что нормализация - это не всегда надо и не всегда есть хорошо. Логические аргументы в том виде, в котором они приведены в литературе не действуют. Хочется знать максимальное число аргументов за и против. Подробно проблема будет описана ниже...

Есть такая объектная модель:

Есть ИЗДЕЛИЯ с атрибутом (КОД)
Внутри изделия есть КОМПОНЕНТЫ с атрибутом (ОБОЗНАЧЕНИЕ)
Каждый компонент состоит из ДЕТАЛЕЙ с атрибутом (ТИП)
У деталей могут быть ВЫВОДЫ с атрибутом (ИМЯ)
Выводы деталей соединены проводами с атрибутами (ВЫВОД1, ВЫВОД2)

Напрашивается такая структура таблиц:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
ИЗДЕЛИЯ (КОД, ИИД)     ИИД -первичный ключ, автоинкрементное поле

КОМПОНЕНТЫ(ОБОЗНАЧЕНИЕ, КИД, ИИД) КИД - ключ, ИИД ссылается в ИЗДЕЛИЯ

ДЕТАЛИ (ТИП, КИД, ДИД)  .....

ВЫВОДЫ (ИМЯ, ДИД, ВИД) ....

ПРОВОДА (ВИД1, ВИД2)  ВИДх - ссылка на ВЫВОДЫ.ВИД
Подразумеваются соответствующие первичные и внешние ключи, в общем все, как учили отцы.

На практике предлагается такая структура
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
ИЗДЕЛИЯ (КОД, ИИД)     ИИД -первичный ключ, автоинкрементное поле

ДЕТАЛИ1 (ИД, ИИД, ТИП, ОБОЗНАЧЕНИЕ)

ПРОВОДА1 (ИД1, ИД2, ИМЯ1, ИМЯ2)

ИДх - ссылка в ИД детали, ИМЯх - имя вывода

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

В общем неделя ожесточенных споров привела меня в параноическое состояние в котором я готов усомниться в собственной вменяемости.
Могут местные отцы высказать аргументы с оценкой (по возможности) насколько действительно так можно или нельзя? По тому, что мы все знаем, что работать будет и так и так....
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.04.2005, 23:35
    #33039484
guest_20040621
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
> Могут местные отцы высказать аргументы с оценкой (по возможности) насколько
> действительно так можно или нельзя? По тому, что мы все знаем, что работать
> будет и так и так....

[Без претензий на местного отца] Работать будут оба варианта.

> Логические аргументы в том виде, в котором они приведены в литературе не
> действуют.

Какие именно аргументы Вы имели в виду, поясните, пожалуйста?

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

Задайте себе вопрос: что будет представлять собой эта база данных через год? Через пять лет? Если это такая одноразовая базенка, ;) imho можно особо не париться над структурой. Если планируется, что она будет расти и развиваться, - см. выше. ;)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 08:51
    #33039669
Va1entin
Va1entin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Одно маленькое замечание.
Поле, являющееся первичным ключом,
лучше делать первым в таблице.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 09:26
    #33039726
Va1entin
Va1entin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Дополнительно. Соображения насчёт нормализации.

Представтьте себе денормализованную базу,
состоящую из нескольких десятков или сотен таблиц.

Разобраться в её структуре (что, согласитесь, необходимо для работы) -
это будет тихий ужас.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 09:45
    #33039762
Сахават Юсифов
Сахават Юсифов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Если дать таблицам и полям понятные названия, то ничего, разберутся.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 10:00
    #33039789
Серега
Серега
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
DarkBoatmanнекие люди утверждают, что нормализация - это не всегда надо и не всегда есть хорошо.
ИМХО, это всегда хорошо, но не всегда производительно, что не хорошо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 11:13
    #33040007
Va1entin
Va1entin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
BTW, 1NF тоже называется нормальной.

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 12:45
    #33040362
softwarer
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
DarkBoatmanНо возник спор, в котором некие люди утверждают, что нормализация - это не всегда надо и не всегда есть хорошо.
Ключевые слова - хранилище данных. Откройте любой материал - будет объяснено, сколько суток будет считаться типичный DWH-запрос в нормализованной схеме.

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

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

DarkBoatmanЗато, мол, так проще писать селект, ибо тут меньше таблиц (А, следовательно, и джойнов...)
Для "проще писать селект" существуют вьюхи. Писать денормализацию и ее софтовую поддержку - может и интереснее, чем селекты, но насчет "проще" я бы поспорил.

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

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

Так или иначе, именно ведущему - PM-у, начальнику или кто у вас за него - следует принять волевое решение. Если Вы будете с ним не согласны - можете смириться, можете искать варианты куда-то перейти.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 12:47
    #33040374
softwarer
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Va1entinПредставтьте себе денормализованную базу,
состоящую из нескольких десятков или сотен таблиц.
Совершенно рядовая ситуация.

Va1entinРазобраться в её структуре (что, согласитесь, необходимо для работы) - это будет тихий ужас.
Да нет, на самом деле. Хотя отсутствие логики и единого подхода, отсутствие документации, невнятное именование и прочие забавные приемы разработки способны сделать этот процесс интересным и полезным упражнением для ума. Впрочем, денормализация здесь особо не при чем; без нее будет то же самое.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 14:08
    #33040472
DarkBoatman
DarkBoatman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Спасибо, вы меня немножко успокоили. Это архив документации предприятия. Представленный фрагмент базы хранит информацию об электрической схеме изделий. И развиваться это будет не один год...
Оттуда эта информация берется технологическими модулями для использования в процессе технологической подготовки производства.
А помещается в базу документооборотным софтом после проверки целостности.
Проблема как раз в том, что САПРА у нас уже 2 и помещающего софта, соответственно назревает тоже, как минимум, 2 варианта.

А начальника нет в природе, то есть есть два разработчика, у которых неожиданно начали пересекаться куски работы. А начальник в этом сам не сечет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 15:25
    #33040752
YBW
YBW
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
DarkBoatmanА начальника нет в природе, то есть есть два разработчика, у которых неожиданно начали пересекаться куски работы.

капец (.) в смыс - точка...

а кто заказчик-то...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 15:35
    #33040803
DarkBoatman
DarkBoatman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Начальник электромонтажного производства взял на работу двух программистов, чтобы автоматизировать документооборот, учет и технологическую подготовку. Он и заказчик и ставит задачу, но, как можно понимать, в ИТ разбирался тогда, когда 36Кб памяти было сверхмного. Он на них решал проблему трассировки печатных плат... А сегодня у нас на повестке вопросы проектирования БД и архитектуры системы, о которых с напарником тяжело догорвориться... Но это уже разговор о тяжелой жизни разработчика, а не о проектировании БД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 15:49
    #33040873
34rtertertety
34rtertertety
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
думаю возможно совместить оба варианта

сама структура БД нормальная (любая достаточная НФ) используются обычные методы поддержания ссылочной целостности данных

а для доступа к данным на чтение обновляемый избыточный денормализованный массив
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 15:50
    #33040881
Хрен
Хрен
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Не насколько действительно полезна нормализациия, насколько действительно вредно ее отсутствие
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 17:41
    #33041321
Va1entin
Va1entin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Мой вам добрый совет: если эти некие
успешно будут вас зажимать своей радиотехникой
пошлите их на хрен и ищите нормальную работу...

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 19:11
    #33041583
Urri
Urri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Нормализованная БД способна обеспечить свою целостность и непротиворечивость одними только связями между таблицами и ограничениями в них. Хранимые процедуры понадобятся только для реализации специфичной бизнес-логики. В этом - плюс нормализации (чисто академический, на практике нормализовать все и вся бывает и вредно).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 21:25
    #33041760
Cat2
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Мои эмпирические правила. Сначала все нормализуется. Потом, если время SELECT начинает превышать некие разумные пределы, критические по скорости расчета поля денормализуются.
Денормализация всегда повышает скорость SELECT и ровно во столько же раз замедляет INSERT, UPDATE и DELETE.

Кстати, Ваш пример очень прост - простые джоины со справочниками, и я бы не стал прибегать к денормализации.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 22:30
    #33041800
DarkBoatman
DarkBoatman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Тогда сразу еще такой вопрос. Все говорят, что в денормализованном виде выборка работает быстрее.
А есть наблюдения, когда сканирование одной большой таблицы с поиском нужных строк становится медленнее, чем сканирование короткого справочника, а потом джойн по числовому ключу?
И еще вопрос, джойн по текстовым полям не может работать быстрее, чем джойн по числовым ключам, я правильно понимаю?
О каком быстрее здесь все мне толкуют?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.04.2005, 22:58
    #33041820
Cat2
Cat2
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
DarkBoatman. О Боже мой! Кто же находясь в здравом рассудке и трезвой памяти сканирует таблицу (не будем вспоминать те редкие случаи, когда курсор действительно выгоднее )? Вы на чем пишете?

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

О каком быстрее? На соединение таблиц в запросе тратится время. При выборке по денормализованной таблице соединения не делаются.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.04.2005, 00:08
    #33041857
DarkBoatman
DarkBoatman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Курсор не причем. Выборка из таблицы с фильтрацией, которая заставляет сервер прочесть ее всю подряд иногда называется scanning.
И тут еще я не сказал (забыл). Что при денормализованном варианте из таблиц все равно потребуется выборка с джойнами. Какие-то выборки будут быстрее, зато другие медленнее. А, например, чтобы получить все выводы компонента придется делать UNION.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.04.2005, 08:37
    #33042000
Va1entin
Va1entin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Если это критично, подумайте об индексации
(хотя бы части, потому что по всем полям индексы - тоже плохо)
полей, по которым производится фильтрация.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.04.2005, 08:57
    #33042018
Сержант Золотарев
Сержант Золотарев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Вот пример, когда нормализация на выходе дает только красоту и дикие тормоза.
Тех задание: создать базу для хранения документов, объем - до одной сотни тысяч. Требования:
- переменный набор атрибутов разного рода (число, дата, трока, значение из справочника.).
- документы требуется сортировать, искать, группировать по произвольной совокупности этих самых искусственныйх атрибутов, время реакции системы в худшем случае - 1 секунда

Ну вот, когда была построена красивая классическая нормализованная структура, при не очень сложных запросах система захлебываться стала уже при 10 000 документов.
Когда переделали на "кирпичный" вариант (жестко забили в таблицу "Документы" сто полей f1...f100), и дабавили менеджер "Логическое поле <-> физическое поле", скорость реакции на машинке P-III, 800 mhz стала не более 0, 5 сек в худшем случае. Естественно, некрасиво, да и проблемы при изменении справочных данных (изменения приходится "в лоб" распространять по всем документам), но из-за небольшого объема (напомню - 100 000 документов) тормозов нет даже при изменении. В этом случае главным было - быстрая выборка.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.04.2005, 10:00
    #33042115
Хрен
Хрен
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Cat2Мои эмпирические правила. Сначала все нормализуется. Потом, если время SELECT начинает превышать некие разумные пределы, критические по скорости расчета поля денормализуются.

... а потом требуется какой нибудь другой запрос, и DBA начинает плясать с бубном и писать программы на перле, пытаясь извлечь информацию из ненормализированной базы
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.04.2005, 10:03
    #33042124
Va1entin
Va1entin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
Сержант,
для тех, кто на бронепоезде повторяю:

Тормозит не нормализация,
а неразумное её использование.

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.04.2005, 11:14
    #33042313
gardenman
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Насколько действительно полезна нормализация?
У меня есть предложение рассмотреть все на небольшом примерчике:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
create table t1 (
   id1 int not null,
   ...
   constraint pk1 primary key (id1)
)
create table t2 (
   id2 int not null,
   id1 int not null,
   ...
   constraint pk2 primary key (id2),
   constraint fk2 foreign key (id1) references t1 (id1)
)
create table t3 (
   id3 int not null,
   id2 int not null,
   ...
   constraint pk3 primary key (id3),
   constraint fk3 foreign key (id2) references t2 (id2)
)
... и т.д.
Т.е. имеем цепочку взаимосвязанных таблиц t1 <- t2 <- t3 <-...<-tn
и другой пример:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
create table t1 (
   id1 int not null,
   ...
   constraint pk1 primary key (id1)
)
create table t2 (
   id1 int not null,
   id2 int not null,
   ...
   constraint pk2 primary key (id1,id2),
   constraint fk2 foreign key (id1) references t1 (id1)
)
create table t3 (
   id3 not null,
   id1 not null,
   id2 not null,
   ...
   constraint pk3 primary key (id3),
   constraint fk3 foreign key (id1,id2) references t2 (id1,id2)
)
... и т.д.

Т.е. как вы думаете когда надо будет пулучить что-то вида:
Код: plaintext
1.
select count(*) from ....tn group by id1
т.е. получить аналитику по id1, в каком случае это будет сделать легче?
в первом случа нужно будет поднять все индексы по всем связанным таблицам, а во втором - только индекс по последней таблице...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Насколько действительно полезна нормализация? / 25 сообщений из 68, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]