Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Избежание переполнения таблиц [D6, IB5.x, IB6.x]

Страницы: < 1 2 3 4 >
Nick-From © (2003-09-05 14:18:00)

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

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. цена, по которой продали

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

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

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

Romkin (2003-09-09 14:06:00) [21]
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_techspec&
НУ что вы волнуетесь? Не тяните на клиента все записи сразу, и хватит вам на пару веков...

MsGuns (2003-09-09 13:29:00) [22]

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

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

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

HSolo (2003-09-09 11:50:00) [23]

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

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

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

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

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

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

>Nick-From ©

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

Sergey13 (2003-09-09 11:06:00) [24]

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

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

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

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

Рамиль (2003-09-09 10:52:00) [25]

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

HSolo (2003-09-09 10:38:00) [26]

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

HSolo (2003-09-09 09:15:00) [27]

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

Jean (2003-09-08 22:57:00) [28]

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

MsGuns (2003-09-08 22:30:00) [29]

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

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

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

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

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

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

Jean (2003-09-08 21:51:00) [30]

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

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

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

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

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

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

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

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

Рамиль (2003-09-08 19:44:00) [32]

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

-=GUEST=- (2003-09-08 19:16:00) [33]

OK

HSolo (2003-09-08 17:37:00) [34]

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

Arm79 (2003-09-08 17:09:00) [35]

2 -=Guest=-

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

-=Guest=- (2003-09-08 16:59:00) [36]

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

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

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

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

-=GUEST=- (2003-09-08 16:52:00) [37]

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

Arm79 (2003-09-08 16:50:00) [38]

>andrey__ (05.09.03 15:57)

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

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

Sandman25 (2003-09-08 16:45:00) [39]

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

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

HSolo (2003-09-08 16:28:00) [40]

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

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »