Избежание переполнения таблиц

← →
Nick-From (2003-09-05 14:18) [0]

Есть таблица товаров на складе:

1. id товара (unique)
2. наименование товара
3. дата изготовления товара
4. дата срока годности товара
5. текущее кол-во товара на складе
6. текущая цена товара

Так же есть таблицы приходных и расходных накладных для учета покупки/продажи товаров.

Приходные накладные:
1. id накладной (не unique, т.к. одна накладная может содержать нескоько товаров);
2. id товара
3. дата оприходования
4. поставщик
5. кол-во купленного
6. цена, по которой закупили

Расходные накладные:
1. id накладной (не unique, т.к. одна накладная может содержать нескоько товаров);
2. id товара
3. дата списания
4. покупатель
5. кол-во проданного
6. цена, по которой продали

Когда товар приходит на склад, в таблицу товаров добавляются соответствующие записи, в таблицу приходных накладных также добавляются записи со ссылками на добавленные записи товаров.
Когда товар списываем со склада, в таблице товаров меняется текущее кол-во товаров, в таблицу расходных накладных также добавляются записи со ссылками на проданные товары.

Проблема в том, что даже когда товар полностью продан и его на складе уже нет, его нельзя удалить из таблицы товаров, т.к. на него ссылаются расходные и приходные накладные. Получается, что таблица будет постоянно пополняться (да и таблицы накладных тоже), что в конце концов со временем будет тормозить базу.

Мастера, подскажите, как решить, можт по-другому организовать таблицы как-то? Два дня вот соображаю - никак. Или это и не страшно, что нет удаления, хотя навряд-ли.

← →
Vlad (2003-09-05 14:20) [1]

Делай индексы и ничего тормозить не будет.
А места в базе тебе на 10 лет вперед хватит

← →
roottim (2003-09-05 14:33) [2]

не завязывай явно на товар... журнал накладных делай автономным
в этом сл. ты можеш делать все что угодно...
связб тебе необходима лиш на момент продажи/...

Расходные накладные:
1. id накладной (не unique, т.к. одна накладная может содержать нескоько товаров);
2. id товара
2.1 наименование
3. дата списания
4. покупатель
5. кол-во проданного
6. цена, по которой продали

← →
DenK_vrtz (2003-09-05 14:38) [3]

Nick-From ©, Vlad © (05.09.03 14:20) [1] дело говорит + теоретически, база в конце года должна скидаваться в архив и чистится (удаляется отработанный материал). Как ты это организуешь - твое право!

← →
Рамиль (2003-09-05 14:38) [4]

> не завязывай явно на товар... журнал накладных делай автономным

Ни в коем случае.
+ шапку и спецификации накладных лучше разделить.
Пока переполнение возникет, программа раз десять успеет устареть:)

← →
Mike Kouzmine (2003-09-05 14:38) [5]

Ты продал товар и забыл? (Удалил карточку). Забавно.

← →
Рамиль (2003-09-05 14:41) [6]

> теоретически, база в конце года должна скидаваться в архив
>

А как получать динамику движения товаров за несколько лет?

← →
DenK_vrtz (2003-09-05 14:48) [7]

Рамиль ©, организовать архивную(ые) таблицу(тыблицы) по годам!

← →
Polevi (2003-09-05 14:55) [8]

не нужно ничего удалять, посчитай сколько у тебя записей будет через 10 лет

← →
Рамиль (2003-09-05 15:01) [9]

> DenK_vrtz ©

Я на корпоративных системах собаку съел.
Делать отчет по нескольким таблицам, должно быть одно удовольствие...

← →
DenK_vrtz (2003-09-05 15:05) [10]

Polevi ©, но согласись, что с организованными архивной(ыми) таблицой(ми) легче и быстрее работать?

Рамиль ©, собак я конечно не ел, но на вкус и цвет..., сам понимаешь :-) О правильной организации данных никто, заметь, не спорит! :-)

← →
Vlad (2003-09-05 15:30) [11]

Архивные таблицы это правильно с точки зрения построения системы.
Но ребяты, посчитайте сами. Пусть даже в день проходит по тысяче накладных. Так за 10 лет это 3 млн записей получится. При наличии индексов в базе - запросы пулей свистеть будут... ну почти пулей.

← →
Polevi (2003-09-05 15:34) [12]

>DenK_vrtz © (05.09.03 15:05) [10]
геморой легче заработать с архивными таблицами, все зависит от колва записей
у меня 2,5 милиона и никаких архивов

← →
HSolo (2003-09-05 15:39) [13]

Может, лучше так:

Номенклатура
1. id товара (unique)
2. наименование товара
(что там еще – фотография, характеристики...)

Приходные накладные:
1. id накладной (unique)
2. номер накладной
3. дата оприходования
4. поставщик

Приход товаров по накладным
1. id прихода (партии товара) (unique)
2. id товара
3. id накладной
4. кол-во купленного
5. цена, по которой закупили

Прайс-лист
1. id строки в прайсе (unique)
2. id товара
3. цена реализации
(что там еще – дата начала действия, скидки, условия...)

Расходные накладные:
1. id накладной (unique)
2. номер накладной
3. дата списания
4. покупатель

Расход товара по накладным
1. id расхода (unique)
2. id накладной
3. id прихода
4. кол-во проданного
5. цена, по которой продали

Это очень упрощенная схема. Скорее всего, Вам понадобится (не сейчас, так потом) резервирование товара, заказ и много чего еще :)
А почему Вы опасаетесь переполнения таблиц? У Вас очень большой объем информации?

← →
andrey__ (2003-09-05 15:57) [14]

Извините, что вмешиваюсь, хотелось бы узнать, сколько максимум записей может вместить SQL таблица и от чего это зависит.

У меня есть таблица в которой 3.500.000 записей и она постоянно наращивается.

← →
Рамиль (2003-09-05 16:00) [15]

> собак я конечно не ел, но на вкус и цвет

Да ты их просто готовить не умеешь:)

> HSolo

Желательна такая цепочка:
Документ основание, накладная, ордер.
В ДО делается резирвирование, после чего создается накладная, при ее списании резерв из ДО сбрасывается.
Прайсов должно быть несколько штук (действующие, в разработке и т. д.)
Накладные можно не разделять, а просто выделить поле под тип накладной.
И Nick-From, а как у вас остатки построены, интересно прос то было бы узнать...

← →
andrey__ (2003-09-05 16:21) [16]

да ну сабок коты лучше

кото нибуть мне ответит.

← →
Vlad (2003-09-05 16:24) [17]

>andrey__ (05.09.03 15:57) [14]
Зависит от типа СУБД и наличии места на диске.
В Аксессе, например, как мне тут недавно подсказали, объем базы м.б. не более 2 ГБ.

← →
MsGuns (2003-09-05 16:26) [18]

ИМХО, стоит прислушаться к Рамиль © & HSolo ©
Хотя модель, приводимая очень упрощенная, но она - живая. Тот же каркас, что в сабже - мертворожденный и при достаточно большом движении просто "задохнется".

По поводу удаления из БД и архивации устаревших данных.
Дело это на 99% излишнее. По крайней мере для нормально выбранного формата БД (сервера) и грамотно организованной топологии и бизнес-логики базы.

← →
Nick-From (2003-09-05 19:54) [19]

Всем большое спасибо за обсуждение!

2 roottim
>не завязывай явно на товар... журнал накладных делай автономным
> 2.1 наименование
А если захочется посмотреть какого срока годности был товар или еще чего, ну фото и т.д., то надо тогда полями 2.2; 2.3; оформлять - дублировать т.е. или не включать такую возможность вообще.

Действительно, схема HSolo мне понравилась гораздо больше :) Буду плясать от нее. tnx 2 HSolo :)

2 Рамиль
> как у вас остатки построены, интересно прос то было бы узнать...
Да никак :) Это мне надо просто лабу сделать по СУБД на IB. Вот взял такую предметную область, хоть как-то ближе к жизни чем подсчет успеваемости студентов :) вот уже и про приход товаров по накладным узнал и про динамику движения товаров за несколько лет :))

Если у кого еще какие предложения, буду только рад выслушать, еще раз всем спсибо!

← →
-=GUEST=- (2003-09-08 15:51) [20]

А как все-таки лучше организовать остатки ?
Есть такая бух. программа - GrossBee, я брал её базу когда IB изучал (рекомендую).
Организуется таблица WAREREST, приблизительно
ID_Tovara
ID_Sklada (у них мультискладской учет)
Ostatok
Rezerv
В которую в процесе работы вносятся изменения, типа
Ostatok = Ostatok - Rashod
Ostatok = Ostatok + Prihod
Естественно не так просто, но идея такая.
На сколько это правильно.
Это самая простая реализация.
Интересно что будет если одновременно вносят изменения два пользователя.

← →
HSolo (2003-09-08 16:01) [21]

Можно и так - если: 1) таблицу вести триггерами, никому для прямого редактирования ее не давать и 2) корректно рулить транзакциями

← →
HSolo (2003-09-08 16:28) [22]

Вдогонку:
Вообще-то идеальный вариант - никаких остатков не хранить, только приходы/расходы, а остатки считать на лету. Но в случае тяжелой выборки (типа оборотной ведомости по всей номенклатуре за достаточно большой промежуток времени) может изрядно падать скорость. Для таких случаев можно организовать таблицу вроде WAREREST (-=GUEST=- (08.09.03 15:51) [20]), только добавить еще дату остатка - и вести ее триггерами. Выборка при этом ускоряется - зато затрудняется ввод документа задним числом и коррекция старых документов (так как нужно пересчитывать остатки). В общем, однозначно ничего тут сказать нельзя, надо смотреть по задаче (объемы данных, характер запросов и пр.)

← →
Sandman25 (2003-09-08 16:45) [23]

>Интересно что будет если одновременно вносят изменения два пользователя.

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

← →
Arm79 (2003-09-08 16:50) [24]

>andrey__ (05.09.03 15:57)

В виндах - ограничение на длину файла.

В MS SQL таблицы можно разнести по нескольким файлам

← →
-=GUEST=- (2003-09-08 16:52) [25]

Такая таблица организована - WareLine
Хранит тип, номер, дату документа и кол-во прихода/расхода.
Когда изменяется WareLine (приход/расход/удаление) пересчитывается остаток(суммируем приход и отнимает расход по WareLine) данного товара и обновляется в WareRest.
Т.е реализованы сразу два подхода.
Все реализовано триггерами.
Единственное, на сколько велика вероятность того, что в процессе работы возникнут расхождения между остатком в табл. WareRest и реальным остатком по таблице движения товаров WareLine (при многопользовательской работе). В идеале нужно блокировать таблицу WareRest и позволять вносить изменения только одному пользователю, но это не в стиле версионного сервера. Если бы было что-то как Gen_ID для генератора.
Возможно я заблуждаюсь?

← →
-=Guest=- (2003-09-08 16:59) [26]

> >andrey__ (05.09.03 15:57)
>
> В виндах - ограничение на длину файла.

В виндах есть NTFS, да и FAT32 до 4Гб - вполне достаточно для средних задач.

> В MS SQL таблицы можно разнести по нескольким файлам

В IB тоже возможны многофайловые базы данных

← →
Arm79 (2003-09-08 17:09) [27]

2 -=Guest=-

Говорю, что знаю.

← →
HSolo (2003-09-08 17:37) [28]

Во-первых, таблицу блокировать совершенно незачем, какой бы ни был сервер; достаточно заблокировать запись (в IB - холостой update). Во-вторых, и в-главных, ничего блокировать не надо, есть другое решение - см. http://ibase.ru/devinfo/pslock.htm
И никаких расхождений не будет.

← →
-=GUEST=- (2003-09-08 19:16) [29]

← →
Рамиль (2003-09-08 19:44) [30]

В "Галактике", например, остатки похожи на GrossBee.
Есть таблица сальдо (приход расход по складам, МОЛам, партиям) и таблица текущих остатков. Она, как я понял, сделана только для убыстрения работы системы, что бы не перещитовать остатки при создании каждой накладной. В результате остатки товара на текущее время получить быстро и элементарно, а что бы отследить на другие периоды надо немножко попотеть.

← →
MsGuns (2003-09-08 21:02) [31]

Схема HSolo "от прихода" (партии, серии, заявки и т.п.), ИМХО, самая "жизненная", но имеет несколько шороховатостей:

1. При коррекции старых накладных (за прошлый месяц,квартал и т.д.) "летят" бух.сальдо (по распечаткам и книгам), поэтому надо жестко контролировать периоды

2. Коррекция приходов зачастую требует откатов расх.накладных, при этом получается что-то типа цепной реакции (не знаю, как выразить, но думаю, что знающие меня поймут сразу). Т.е. исправление операторских ошибок (и не только) часто чревато большим гемором для оператора-бухгалтера или даже программера.

3. Несколько громоздок процесс списания товара, т.к. приходится иметь дело не с объектом типа "Наименование товара", а с целым перечнем ссылок на соотв.приходы, каждый возможно со своей ценой и т.д. Приходится применять средства автоматизации (FIFO/LIFO/ROF и т.д.) и изгаляться при печати документов (заменять много строчек на одну) и т.д.

Есть еще и специфические недостатки этой технологии, но в целом такая схема оправдана, т.к. защищена от всевозможных "фокусов" клиента лучше остальных, в частности описанную -=GUEST=- (базированную на хранении тек. остатков).

← →
Jean (2003-09-08 21:51) [32]

А насколько удобно мое решение для локальной БД.
Имеем 3 таблицы: Склад, Приход и Расход + 2 временных: РасходВр и ПриходВр.
Работает система след. образом:
В Складе храниться то, что есть на данный момент на складе.
Когда добавляем товар (ставим на приход) он первоначально заносится в таблицу ПриходВр, а после, когда пользователь завершил добавление товара происходит полный расчет и изменение количества товара на Складе. В случае успешного выполнения ПриходВр очищается. В случае сбоя - информация в ней остается, но обработанные записи помечаются "+".
С расходом аналогично.

Особенности в том, что не нужны накладные, прайсы и разные бух. отчеты. Необходимы просто продажи, приход и остаток за опред. период.

← →
MsGuns (2003-09-08 22:30) [33]

>Jean © (08.09.03 21:51) [32]
>А насколько удобно мое решение для локальной БД

Пежде всего. А что, если БД локальная, то можно "похерить" и бухучет, и многоценье ?

Не понятно с объектом "Склад". Если это список фактически наличия товара на складе, то много вопросов:
а) А если склад не один ?
б) Если товар ушел в 0, т.е. продан, то вон его из базы ?
в) При ПриходВР, т.е. приход есть, но он еще не прогрегистрирован, то и отпуск (выписать счет, например) его невозможен ?

В целом непонятна фраза "Особенности в том, что не нужны накладные, прайсы и разные бух. отчеты."
Это что, если бух потребует, например, журнал по "товарным" счетам, то ему вежливо предложить купить другую прогу ?

Я уж молчу про оплату и вообще возможности анализа состояния взаиморасчетов с контрагентами (постащиками и покупателями)

ИМХО, такая система может пригодиться на складе кладовщику, но никак не менеджерам, дирекции, торговому отделу и т.д. Вообще молчу уже о рознице, списание товаров в переработку и т.д.
Даже будучи ЧП (частный предприниматель), я бы такую программу и даром не взял.

← →
Jean (2003-09-08 22:57) [34]

Ясно все... если я задам след. вопрос, то скажут перечитай, поэтому я его не задаю. Но такая система нужна именно кладовщику и никому более!

← →
HSolo (2003-09-09 09:15) [35]

Ничего не понимаю (с)
Какой смысл в задаче, нужной "именно кладовщику и никому более"?
А все прочие (менеджеры, бухгалтерия...) на счетах щелкают? %))

← →
HSolo (2003-09-09 10:38) [36]

> MsGuns © (08.09.03 21:02) [31]
Все так, на 150%. Только один маленький нюанс: а при какой схеме в случае коррекции старых документов бух.сальдо НЕ полетят? Разве что если оные сальдо хранить отдельно, в текущем (открытом) периоде - пересчитывать, а в закрытых периодах - не трогать, а формировать корректирующий документ в текущем периоде; тоже, конечно, муторно, но... а какие варианты?

← →
Рамиль (2003-09-09 10:52) [37]

1. Работу в закрытом переоде надо категорически пресекать (например, Парус)
2. На крайний случай существует сторно.

← →
Sergey13 (2003-09-09 11:06) [38]

Господа. Ну вы разошлись. 8-)

>Nick-From © (05.09.03 19:54) [19]
>Это мне надо просто лабу сделать по СУБД на IB.

А вы ему советы для кандидатской даете. 9-)

2Nick-From ©
Делай как написал в вопросе - чем таблиц меньше - тем писАть меньше. Работать будет - как? в лабе не обсуждается. За время твоей лабораторной работы таблицы не переполнятся. 8-)

← →
HSolo (2003-09-09 11:50) [39]

> Sergey13 © (09.09.03 11:06) [38]

ПОлно, Вы ли это? Чему Вы учите молодое поколение ??? :))

> А вы ему советы для кандидатской даете. 9-)

Для какой такой кандидатской??? Для обычной "базенки по шоколадкам" (c) кто-то в FIDO пару лет назад.

> Делай как написал в вопросе - чем таблиц меньше - тем писАть меньше. Работать будет - как? в лабе не обсуждается. За время твоей лабораторной работы таблицы не переполнятся. 8-)

А потом придет такой специалист к Вам на работу. И напишет приложение в полном соответствии с Вашими советами, ибо иначе не умеет. И хорошо, если к Вам... :)) а вдруг ко мне, или к MsGuns, или к Рамилю? Не хотим! :))

>Nick-From ©

"Ты его не слушай, он тебя плохому научит" (с)

← →
MsGuns (2003-09-09 13:29) [40]

>HSolo © (09.09.03 11:50) [39]
>А потом придет такой специалист к Вам на работу. И напишет приложение в полном соответствии с Вашими советами, ибо иначе не умеет. И хорошо, если к Вам... :)) а вдруг ко мне, или к MsGuns, или к Рамилю? Не хотим! :))

Мало ли что мы не хотим ! Придет. Напишет. Плохо. Мы научим. Опять напишет. Опять плохо. Мы научим... И так в цикле.

Пока не научим. Или не выгоним. Или сам не уйдет. Это життя.

Избежание переполнения таблиц Найти похожие ветки