|
|
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Всем привет! Есть небольшая база. Её назначение на данном этапе: складывать результаты проведения учений и отображать их в виде одной большой развернутой таблицы, в которой сведены все джойны. Так вот, вопрос вот в чем: а что плохого, чтобы в базе данных была только одна денормализованная таблица? Я вот нутром чувствую, что оно не красиво... А почему - объяснить не могу... Вы то как думаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 19:11 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Нормальная форма — требование, предъявляемое к отношениям в теории реляционных баз данных для устранения из базы избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 20:30 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Vetal wrote: > Так вот, вопрос вот в чем: а что плохого, чтобы в базе данных была > только одна денормализованная таблица? 0) Таблица может "лопнуть". В СУБД обычно есть ограничения на количество полей в таблице и физическую длину записи (не более длины одной страницы БД). Ваша денормализованная запись может тупо не влезть в эти ограничения. 1) Таблица будет хранить много лишних данных. Собственно, чтобы не хранить в избытке, несколько раз, одни и те же данные и придумали нормализацию. В таком случае ваша таблица будет слишком "длинной" и "жирной", т.е. её будет тупо труднее читать с диска и в конце концов производительность её обработки упадёт. Я лично имел опыт денормализации таблицы "для повышения производительности". Сначала это работало, но с ростом объёмов данных рост денормализованной таблицы был квадратичный или кубичный, и в итоге денормализованная таблица тупо перестала влазить в кэш СУБД и производительность запросов с ней перестала рости, так что пришлось перейти обратно на JOIN-ы. Это где-то на 5-10 млн записей начинается (тут всё от записей и объёма кэша зависит, конечно). Это - две основные проблемы ДЕнормализованной таблицы. Это значит, что у вас было всё сначала нормализовано, а потом физически сохранялась продукция нормализованных таблиц. Если это просто НЕнормализованная структура, и она меняется, то сюда ещё добавяться аномалии несогласованности данных. Типа 3 раза стрелял один и тот же рядовой Иванов Петр Эдгарович, два раза он был внесён как "Иванов Петр Эдгарович", а третьий раз - как "Иванов Петр Ейгарович". Теперь вопрос: какое отчество у Иванова. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 20:40 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Так или иначе все упрется в обработку этих таблиц... Где, с ростом числа записей и количества полей, нормализованые таблички будут обгонять по производительности ненормализованые. ---------- Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 21:39 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
MasterZiv....Вот все это укладывается в несколько слов: если хочешь заниматься любовью с несоответствием данных в разных источниках - пользуйся денормализованными таблицами. Автор, Чем плохо загонять используемые константы в код программы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2009, 21:44 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Vetal, За начальную простоту ненормализованной таблицы при увеличением объема данных и при необходимости выполнить более-менее сложный запрос придеться платить потерей производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 08:39 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
В целом коллеги всё правильно говорят... И про НФ и прочее сейчас ещё много чего расскажут и без меня. Однако не всё так однозначно в мире данных. Денормализация подчас может и ускорить процесс: RTFM Хранилища данных, star scheme, snowflake etc. Всё зависит от требований и ожиданий, которые выставляются к данной базе. PS: не забываем что join-ы тоже ресурсоёмки. И нечто подбное log-ам, может быть эффективнее хранить не в нормальной форме. А если на это ещё и OLAP tool какой-то навишивают.... 2Vetal: плохого - если вдруг какой-то классификатор меняется - тебе нужно делать массовый апдейт по этой таблице (либо не надо, если нужно сохранить ИСТОРИЧЕСКИЕ данные - как они были тогда) - тут уж как я говорил - какие требования выставлены. Плюс одни и те же литералы хранятся по несколько раз - это стоит дороже в плане места. Однако место на HDD сейчас стоит не так уж дорого, потому снова таки - выходим из требований и строим по ним (в дискусии по затратам на блочные чтения итд вдаваться не буду сейчас ибо исходная информация - база маленькая). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 14:23 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
DenKrep wrote: > PS: не забываем что join-ы тоже ресурсоёмки. И нечто подбное log-ам, > может быть эффективнее хранить не в нормальной форме. А если на это ещё > и OLAP tool какой-то навишивают.... Ага, рассказывай. Как раз в логах ещё надо 100 раз подумать, прежде чем денормализировать, потому что там объёмы данных большие. У нас вызовы логируются, с параметрами. Были бы ненормализованные таблицы, кол-во записей в таблице лога увеличилось бы в среднее число параметров вызова (сама таблица параметров с узкой записью, короткая). Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 16:12 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Хорошо. Насчёт больших баз данных - однозначно нормализация рулит! А вот если у меня в базе никогда не будет больше нескольких десятков тысяч записей - есть ли смысл использовать денормализованную таблицу, или лучше всё-таки нормализовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 16:36 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Vetal, делать сразу хорошо, а плохо само получится. Нормализовать небольшую базу просто, а вот потом разгребать ненормализованное г... с актуальными данными внутри - отвратительное занятие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 17:31 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
VetalА чем плохо хранить все данные в одной ненормализованной таблице? а ты снеси все внутренние стены в своей квартире и сразу врубишся че к чему :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2009, 19:07 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Запросы сложнее получаются для разделения данных, соответственно все дольше работает. Я просто в одной таблице объединил шапки и табличные части самых разных документов с самой разной структурой. Так лучше не делать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2009, 12:30 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
egorychVetal, делать сразу хорошо, а плохо само получится. Нормализовать небольшую базу просто, а вот потом разгребать ненормализованное г... с актуальными данными внутри - отвратительное занятие.+1000. Но к сожалению, иногда, это не аргумент извините, что поднимаю древнюю тему, но не хотелось бы плодить топики. Похожая ситуация Есть небольшая служебная БД, используется для хранения метаданных. Возник "философский" спор: нужно ли всё засунуть в одну таблицу, или разнести разные сущности в разные таблицы. Мне кажется настолько естественным нормализовать БД, что даже сходу не смога найти аргументы на вопрос "а зачем?". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.08.2010, 22:21 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
NafНормальная форма — требование, предъявляемое к отношениям в теории реляционных баз данных для устранения из базы избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. С уважением, Naf Вы все перепутали. Как раз изменения в сильно нормализованной базе могут легко привести к потере данных, в отличие от денормализованой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2010, 01:03 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Хопа, Дааа? Пример можете привести? И что значит сильно нормализована? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2010, 15:30 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
VetalВсем привет! Есть небольшая база. Её назначение на данном этапе: складывать результаты проведения учений и отображать их в виде одной большой развернутой таблицы, в которой сведены все джойны. Так вот, вопрос вот в чем: а что плохого, чтобы в базе данных была только одна денормализованная таблица? Я вот нутром чувствую, что оно не красиво... А почему - объяснить не могу... Вы то как думаете? Если база небольшая и в дальнейшем не предполагается её рост и полей не более 20 штук, то вполне можно обойтись и одной таблицей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2010, 22:53 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
ValGer... Если база небольшая и в дальнейшем не предполагается её рост и полей не более 20 штук, то вполне можно обойтись и одной таблицей. ога, вот так оно обычно и начинается - "да скока той зимы тех данных ! - и так сайдёт !" вот только и заканчивается, тоже всегда одинаково - плохо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2010, 23:05 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
VetalХорошо. Насчёт больших баз данных - однозначно нормализация рулит! А вот если у меня в базе никогда не будет больше нескольких десятков тысяч записей - есть ли смысл использовать денормализованную таблицу, или лучше всё-таки нормализовать? Забыть про субд,сиквел, и пр. проглjтить в память и получить полную свободу хранения, поиска, представления, в соответствие с предметной областью.... в 1992г внедрял(официально купив) nwsql а xbase гуру крутили у виска, а теперь я кручу показывая на тех, кто в любую дырку пытается запихнуть sqlsrv ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2010, 23:10 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Лень регитьсяХопа, Дааа? Пример можете привести? И что значит сильно нормализована? Ага. Весь год магазин продавал трусы и добавлял записи в две таблицы - нормализованную и денормализованную. Потом трусы кончились и поступили майки с тем же артикулом. Бух поправила название товара... дальше рассказывать про то, как по отчету по нормализованной таблице оказалось, что магазин торговал майками целый год? А в денормализованной таблице, как ни странно, все осталось на своих местах и отчет получился правильным. Вывод - immutable данные рулят. А update придумали идиоты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2010, 10:01 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
ХопаПотом трусы кончились и поступили майки с тем же артикулом.пример такой мутации в студию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2010, 12:58 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Ага. Весь год магазин продавал трусы и добавлял записи в две таблицы - нормализованную и денормализованную. Потом трусы кончились и поступили майки с тем же артикулом. Бух поправила название товара... дальше рассказывать про то, как по отчету по нормализованной таблице оказалось, что магазин торговал майками целый год? А в денормализованной таблице, как ни странно, все осталось на своих местах и отчет получился правильным. Вывод - immutable данные рулят. А update придумали идиоты О! Буду использовать на собеседованиях. Кто не сможет возразить - сразу, до свидания! ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2010, 14:03 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
VetalВсем привет! Есть небольшая база. Её назначение на данном этапе: складывать результаты проведения учений и отображать их в виде одной большой развернутой таблицы, в которой сведены все джойны. Так вот, вопрос вот в чем: а что плохого, чтобы в базе данных была только одна денормализованная таблица? Я вот нутром чувствую, что оно не красиво... А почему - объяснить не могу... Вы то как думаете? Если речь идет о схеме БД Ну обычно есть риски аномалий ввода и удаления, и конечно же контроля избыточности. У даления: напримр, есть склады и есть там всякие товары. Вот нет ни одного товара на складе таком-то, то этот склад нуно либо тепрь удалить из этой обльшой таблы, (также незя добавить склад без товаров). Ну разве что с пустыми товарами. Но это тоже типа мусор редкостный в БД набирается. Избыток: у вас товары одной фирмы - нуно каждый раз повторять все реквизиты фирмы (как правило операторы интуитивно этого не делают - получается типа пустые значения, т.е. они как бы типа мыстленно нормализуют). Теперь ошибка в реквизите: нуно все просматривать везде править - проблемы контроля избыточности. В общем все это ведет к рискам потерь данных. Отдельно риски гемором с ОЦ, и в общем случе с написанием запросов могут вознкать как отдельный приз. Часто прежде чем написать запрос нуно еще написать несколько проверочных, чтобы понять на скока все плохо с данными. И запрос тоже писать с учетом косяков в данных. Если речь идет о каком-то представлении для отчета, а представлени получено из нормальных таблов, то ниче: ну это просто промежуточный запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2010, 16:28 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
egorychХопаПотом трусы кончились и поступили майки с тем же артикулом.пример такой мутации в студиюНу пример-то как раз легко привести (ничуть при этом не выступая за денормализованные таблицы). Поступали нам оные спортивные трусы от ООО "Торпедо" с ИНН 111111111111, а потом ООО реорганизовалось в ЗАО "ЗИЛ" с ИНН 22222222222. Все договора с контрагентом продолжают действовать, даже банковские реквизиты могут остаться теми же - мы просто в БД ИНН и название у контрагента поменяли. И опа... Все счета-фактуры за прошлый год сами собой поменялись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 13:21 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyООО "Торпедо" с ИНН 111111111111, а потом ООО реорганизовалось в ЗАО "ЗИЛ" с ИНН 22222222222. Все договора с контрагентом продолжают действовать, даже банковские реквизиты могут остаться теми же - мы просто в БД ИНН и название у контрагента поменяли. И опа... Все счета-фактуры за прошлый год сами собой поменялись.Да? Что, правда? И даже банковские реквизиты те же остались? У новой-то компании. Пруф в студию, пока своими глазами такое не увижу, не поверю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 13:54 |
|
||
|
А чем плохо хранить все данные в одной ненормализованной таблице?
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyegorychХопаПотом трусы кончились и поступили майки с тем же артикулом.пример такой мутации в студиюНу пример-то как раз легко привести (ничуть при этом не выступая за денормализованные таблицы). Поступали нам оные спортивные трусы от ООО "Торпедо" с ИНН 111111111111, а потом ООО реорганизовалось в ЗАО "ЗИЛ" с ИНН 22222222222. Все договора с контрагентом продолжают действовать, даже банковские реквизиты могут остаться теми же - мы просто в БД ИНН и название у контрагента поменяли. И опа... Все счета-фактуры за прошлый год сами собой поменялись. Решается хранением исторических данных. И что у вас за нужда на регулярной основе печатать первичку за прошлые периоды? В книгах покупок/продаж ИНН у вас тоже меняется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2010, 13:54 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35953057&tid=1542573]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
181ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 511ms |

| 0 / 0 |
