ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Насколько действительно полезна нормализация?
25 сообщений из 68, страница 1 из 3
  1  все
Насколько действительно полезна нормализация?
    #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, 21:42
| Ответить | Цитировать | Написать  
Насколько действительно полезна нормализация?
    #33039484
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Могут местные отцы высказать аргументы с оценкой (по возможности) насколько
> действительно так можно или нельзя? По тому, что мы все знаем, что работать
> будет и так и так....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
29.04.2005, 10:03
| Ответить | Цитировать | Написать  
Насколько действительно полезна нормализация?
    #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
29.04.2005, 11:14
| Ответить | Цитировать | Написать  
25 сообщений из 68, страница 1 из 3
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Насколько действительно полезна нормализация?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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