|
|
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
Здравствуйте ! Имеется база данных, основное назначение которой оперативная выписка и ввод документов. Одна из главных таблиц в ней таблица с товарами где хранятся названия, номенклатурные номера, прочие различные атрибуты. Среди прочих главные: остатки по складам (поле номер склада в них остаток, с десяток разных). Основаная выписка проходит с двух складов. Таблица денормализована. Записей в таблице ~70000. В книжках прочитал что транзакционные базы данных должны буть нормализованны по максимуму, но мы имеем такую. Внимание вопрос будет ли прирост производительности если эту таблицу нормализовать, что вообще можно с ней сделать ? Работа эта большая, а будет ли толк. По своему скудоумию оценить не могу помогите пожалуйста сирому !? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 08:57 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ГорбатыйЗдравствуйте ! Имеется база данных, основное назначение которой оперативная выписка и ввод документов. Одна из главных таблиц в ней таблица с товарами где хранятся названия, номенклатурные номера, прочие различные атрибуты. Среди прочих главные: остатки по складам (поле номер склада в них остаток, с десяток разных). Основаная выписка проходит с двух складов. Таблица денормализована. Записей в таблице ~70000. В книжках прочитал что транзакционные базы данных должны буть нормализованны по максимуму, но мы имеем такую. Внимание вопрос будет ли прирост производительности если эту таблицу нормализовать, что вообще можно с ней сделать ? Работа эта большая, а будет ли толк. По своему скудоумию оценить не могу помогите пожалуйста сирому !? В теории - все должно нормализовываться. На практике - не всегда так. Иногда, для ускорения получения результатов (чтобы не выполнять сложные запросы), делают частичную денормализацию. Правда, такое практикуется чаще всего в OLAP/Data Warehouses - системах, а не в OLTP... С другой стороны, если таблицу нормализовать "по максимуму", то ускорения работы может не произойти и даже может произойти замедление(!). Как "+" - в нормализованной таблице можно возложить на сервер БД много работы по контролю непротиворечивости данных (constarints), которую иначе потребовалось бы вести вручную/через Хранимые процедуры/триггеры.... Вообще мое мнение (как практика): "Система работает? Да? Ну и не трожь ее!!!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 09:13 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
Горбатый пишет: > но мы имеем такую. Внимание вопрос будет ли прирост производительности > если эту таблицу нормализовать, что вообще можно с ней сделать ? Работа > эта большая, а будет ли толк. По своему скудоумию оценить не могу > помогите пожалуйста сирому !? Это зависит от конкретики системы. Как ненормализована таблица, в каких запросах участвует. Одно не понятьно - 70000 записей - достаточно скромные объемы данных, там все должно быстро работать. Видимо все же у вас кроме ненормализованности еще и в приложениях полная каша. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 09:33 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
Я же говорю в таблице кроме инормации о товаре храняться остатки. Для тех кто в бронепоезде структура сокращенно (GoodsID, Nomnum, ... W_1,W_2...W_12,...GoodsKindID) Одновременно с ней работает около 30 юзеров. Выписывая товары делаетяся апдейт полю с остатком. Выписка идет с нескольких складов. OLAP не главное главное выписка. Трогать ничего не хочется, но вот начальники они расстраиваются из-за тормозов. Что-то нужно сделать или грамотно мотивировать бездействие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 10:12 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
Горбатый пишет: > Одновременно с ней работает около 30 юзеров. Выписывая товары делаетяся > апдейт полю с остатком. Выписка идет с нескольких складов. OLAP не 30 пользователей. 70000 записей. Что ж там может тормозить ? Ну даже если у них в одной записи по всем складам остатки храняться, и пользователи все в одну запись тычятся, то все равно по идее не должно быть так это критично. Сколько проходит изменение остатка ? Ну пусть секунду. что ж им пару секунд не подождать ? Я думаю, что тебе надо выяснить сначала конкретно, какие запросы к каким данным порождают конкуренцию по доступу к данным, а потом ты уже сможешь понять, виной ли там ненормализацованность таблиц, или нет. Ненормализованность страшна более теоретическими последствиями, напр., ты не сможешь хранить данные по более чем N складам. Но для производительности как правило достаточно все равно (не абсолютно все равно). Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 10:30 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
Может и не всегда нужна нормализация, но держать остатки по складам в полях под каждый склад в справочнике номенклатуре это ЖЕСТЬ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 10:32 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ГорбатыйВ книжках прочитал что транзакционные базы данных должны буть нормализованны по максимуму, но мы имеем такую. Внимание вопрос будет ли прирост производительности если эту таблицу нормализовать, что вообще можно с ней сделать ? Работа эта большая, а будет ли толк.Денормализация, как правило, ускоряя выборку данных, может сильно замедлить модификацию данных. Поэтому ее применение типично, как тут уже заметили, для систем анализа данных. Основной причиной торможения в вашем случае, если правильно понял ситуацию, могут являться блокировки, учитывая, что работаете вы с блокировочником, если судить по вашему профилю. Есть подозрение, что интересы пользователей часто пересекаются на одних и тех записях, хотя по смыслу этого быть не должно. Типичный пример, пользователи оперируют одним и тем же товаром, но из-за того, что остатки для каждого склада находятся в одной и той же записи, то они будут постоянно сталкиваться по интересам и будут вынуждены ждать друг друга. Надеюсь, что при этом транзакции используются ровно столько, сколько необходимо для обеспечения непротиворечивости данных, а не открываются в момент, когда пользователь решил редактировать, а закрываются, когда он допил кофе. Речь пока не идет о правильной индексации, которая может сильно повысить общую производительность, возможно у вас идет постоянное сканирование(scan), вместо точного поиска(seek). IMHO, переделывать надо, и обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 13:56 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > Денормализация, как правило, ускоряя выборку данных, может сильно > замедлить модификацию данных. Поэтому ее применение типично, как тут уже Это не ДЕнормализания. Это НЕнормализация. Для того, чтобы была ДЕнормализация, надо БД сначала нормализовать, а потом денормализовать. И при этом обычно таблица остается во 2-ой или 1-ой НФ. А это - не тот случай. Тут 1НФ нарушается. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 14:41 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > Денормализация, как правило, ускоряя выборку данных, может сильно > замедлить модификацию данных. Поэтому ее применение типично, как тут уже Это я к тому, что замечание не к месту. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 14:41 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто не ДЕнормализания. Это НЕнормализация. Для того, чтобы была ДЕнормализация, надо БД сначала нормализовать, а потом денормализовать. И при этом обычно таблица остается во 2-ой или 1-ой НФ. А это - не тот случай. Тут 1НФ нарушается.Благодарю, Вы открыли мне веки :) Кстати, не будете ли так любезны, процитировать место из топика автора, где Вы обнаружили нарушение 1НФ ? MasterZivЭто я к тому, что замечание не к месту.Предлагаю это решить автору темы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 15:23 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
Сейчас начну открывать военные тайны. Как уже говорил ранее выписка осуществляется с нескольких складов. Если на одном складе товара не хватает, то он выписывается с другого. Далее самое интересное в этой же таблице хранятся остатки по фирмам (у нас их несколько, а база одна) и склад закреплен за несколькими фирмами. Товар может одновременно числиться на нескольких фирмах А,В,С лежа на складе А. Структура: GoodsID..W_1,W_2,...F_1,F_2 и т.д.). Т.е товар выписывается со склада, сразу же и с фирмы. Так вот получается онлайн или как мы называем живая выписка. В любой момент времени видно ситуацию на складе и фирме. Зачем ? Так велено. Вся эта механизма поддерживется триггерами. Мысля по нормализации во какая: создать отдельные таблицы типа (GoodsID,W_1) и (GoodsID,F_1). Написать ряд триггерочков по поддержке правил. Вот стоит ли все это ? Работа-то каторжная. Если не стоит, то чего делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 15:34 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
[quot ChA] Надеюсь, что при этом транзакции используются ровно столько, сколько необходимо для обеспечения непротиворечивости данных, а не открываются в момент, когда пользователь решил редактировать, а закрываются, когда он допил кофе. Панимаите теперь что разных действий очень много. Да исчо регистрация изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 15:38 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ГорбатыйМысля по нормализации во какая: создать отдельные таблицы типа (GoodsID,W_1) и (GoodsID,F_1). Написать ряд триггерочков по поддержке правил. Вот стоит ли все это ? Работа-то каторжная. Если не стоит, то чего делать.Судя по Вашему настрою, то не стоит, пусть кто-нибудь другой этим занимается. P.S. Вам в принципе надо менять подход, IMHO. Отказаться от хранения актуальных остатков, ну разве что, при больших оборотах, фиксировать остаток на начало месяца, например. А получать актуальный остаток простым суммированием. Это будет выполняться достаточно быстро, зато конфликтов между пользователями будет значительно меньше. Кроме того, так как товар одновременно "принадлежит" фирме и складу, то, возможно, вместо приведенных Вами 2-х таблиц лучше использовать одну, "типа" (GoodsID, WareHouseID, FirmID, ...), которая будет отражать "атомарное" движение товара между владельцами. Заодно решается проблема логгирования, если добавить соответствующие поля в таблицу. Более точно, какой структуры желательно иметь таблицы можно сказать, только имея дополнительную информацию. Впрочем, это только направление, дальше, как мне кажется, Вам стоит подумать самому. Кстати, я бы не рекомендовал сильно увлекаться триггерами, иногда процедуры могуть стать более предпочтительным решением, но может и нет, зависит от нюансов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 16:21 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > процитировать место из топика автора, где Вы обнаружили нарушение 1НФ ? Там несколько остатков хранится в одной записи, я не ошибся ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 16:56 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
MasterZivТам несколько остатков хранится в одной записи, я не ошибся ?И Вы считаете, что это признак 1НФ ? IMHO, Вам стоит освежить свои знания теории. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 16:59 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > Там несколько остатков хранится в одной записи, я не ошибся ? > > И Вы считаете, что это признак 1НФ ? IMHO, Вам стоит освежить свои > знания теории. Да, именно это оно и есть. Если у вас другое мнение, оно неправильное. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 17:02 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
MasterZivДа, именно это оно и есть. Если у вас другое мнение, оно неправильное.Уже не смешно, уже грустно. Поройтесь в Google, что ли... Вот Вам Википедия , на всякий. P.S. Сказать глупость, это еще полбеды, но настаивать на ней ? P.P.S. В топике автора можно усмотреть, в лучшем случае, нарушение 3НФ - зависимость между значениями неключевых атрибутов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 17:32 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > Уже не смешно, уже грустно. Поройтесь в Google, что ли... Вот Вам > Википедия <http://ru.wikipedia.org/wiki/Нормальная_форма>, на всякий. Ну так что такое W_1,W_2,...F_1,F_2 и т.д. ? W_1,W_2,... - массив значений. Т.е. неатомарный атрибут. Если бы СУБД поддерживала массивы, ты мог бы это запихать в одну колонку W, но ты не можешь, а изображаешь массив в виде суффикса имени колонки. Надеюсь, что ты согласен, что массив в поле - это нарушение 1НФ ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 18:44 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
MasterZivИзвините, но не вижу смысла продолжать дискуссию, времени жалко. Можете продолжать себя убеждать, что все так и есть, как Вы пишете, но это ни на йоту не добавит убедительности Вашим рассуждениям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.07.2007, 19:01 |
|
||
|
Ненормальная таблица
|
|||
|---|---|---|---|
|
#18+
ChA пишет: > Извините, но не вижу смысла продолжать дискуссию, времени жалко. ОК, не продолжай. Мне это тоже не интересно. > Можете > продолжать себя убеждать, что все так и есть, как Вы пишете, но это ни > на йоту не добавит убедительности Вашим рассуждениям. Я искренне думал, что ты что-то не понимаешь, и хочешь понять. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.07.2007, 14:36 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=34670210&tid=1544398]: |
0ms |
get settings: |
11ms |
get forum list: |
24ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
172ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 557ms |
| 0 / 0 |
