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

← →
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, или к Рамилю? Не хотим! :))

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

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

← →
Romkin (2003-09-09 14:06) [41]

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_techspec&
НУ что вы волнуетесь? Не тяните на клиента все записи сразу, и хватит вам на пару веков...

← →
HSolo (2003-09-09 14:12) [42]

> MsGuns © (09.09.03 13:29) [40]
Уговорили :) Пусть к Вам приходит :)) И ко мне придет - научу, куда ж я денусь... Не об этом речь. А о том, что не надо учить человека делать неправильно. Ваши же слова :))

← →
MsGuns (2003-09-09 16:53) [43]

>HSolo © (09.09.03 14:12) [42]
>А о том, что не надо учить человека делать неправильно. Ваши же слова

Ну, говорить прописные истины - много ума не нужно ;))
Так ведь все равно учили, учат и будут учить ! И с этим ничего не поделаешь. Но хотеть, как говорится, не вредно.

← →
kaif (2003-09-09 19:41) [44]

Я в своей системе Allergo применяю такой подход:

Накладные приходные (2 таблицы)
Накладные расходные (2 таблицы)
Две хранимые процедуры, генерящие формат журнала проводок и имеющие ID документа в виде входного параметра.
Таблицу проводок ACC_TURN в формате примерно таком:

Дата проводки, ID счета, ID объекта, ID слоя, ID документа,
Сумма Дебет, Сумма Кредит, Кол-во Дебет, Кол-во Кредит.

В качестве счета выступают разные склады.
В качестве объекта в этом случае выступает товар из справочника товаров.
В качестве слоя подразумевается валюта операции.

При сохранении накладной удаляются все проводки с ID документа и запускается INSERT INTO ACC_TURN SELECT FROM NAKL_TEMPLATE(:ID), где NAKL_TEMPLATE - процедура, поставляющая формат журнала проводок.

В результате, если нужно узнать текущие остатки товаров на любую дату на любом складе можно просто сделать
SELECT OBJECT_ID, SUM(QUANTITY_DEBIT - QUANTITY_CREDIT)
FROM ACC_TURN
WHERE ACC_ID = :ID склада AND
OPER_DATE <= :дата
GROUP BY OBJECT_ID

Если нужно знать себестоимость остатков:
SELECT OBJECT_ID,
SUM(DEBIT - CREDIT)/
SUM(QUANTITY_DEBIT - QUANTITY_CREDIT)
FROM ACC_TURN
WHERE ACC_ID = :ID склада
GROUP BY OBJECT_ID
HAVING
SUM(QUANTITY_DEBIT - QUANTITY_CREDIT) <> 0

Эта себестоимость используется в расходных накладных (прямо в таблицах в момент создания этих документов)

Хранимые процедуры берут данные из таблиц документов и формируются автоматически путем настройки "шаблона операции".

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

Обратите внимание на то, что формат журнала проводок отличается от принятого у нас и похож на GAAP.

Это очень приблизительное описание одной конфигурации моей системы Allegro (альтернативы 1С).

Скорости хорошие. Полный бухгалтерский баланс на 22000 проводок занимает 0.3 сек и делается 1 запросом. Ни один запрос не длится больше долей секунды. Будь то остатки, стоимости или еще чего.

← →
Jean (2003-09-09 20:40) [45]

> HSolo: Странный ты. Если кладовщик просит программу, почему я должен делать ее еще и на бухгалтеров, менеджеров и др. персонал, которого может и в кладовке-то нету???!!!

← →
Nick-From (2003-09-09 23:32) [46]

Да, возьмите меня к себе работать ;) только через год :)) по окончании института =)

Конечно схемы бд были приведены очень даже ничего, большинство бухгалтерских изощрений я так и не просек еще, но с Sergey13 всетки не согласен: пусть будет, возможно чуть сложнее реализовываться, но зато красиво, сделаешь и глаз радует :)
(Я кладу на другие предметы :)) )

А если серьезно, то такие вот вопросы есть исчо:

2 HSolo © (08.09.03 16:28)
> Но в случае тяжелой выборки (типа оборотной ведомости по всей >номенклатуре за достаточно большой промежуток времени) может >изрядно падать скорость.

А при простом расчете остатка по какому-то товару разве запрос будет пробегать не по всей номенклатуре? Или это Вы имеете ввиду то, что для МНОГИХ товаров придется внутри запроса рассчитывать остатки "на лету" и это будет причиной тормозов, нежели просто выборка из дополнительной таблицы?

и исчо:
>только добавить еще дату остатка - и вести ее триггерами
Что значит "вести ее триггерами"? Типа все изменения в ней происходят через срабатывание триггеров на таблицах по приходу и расходу товаров?

и исчо:
Чего-то не понял зачем нужна дата в дополнительной таблице остатков? Ведь остаток товара можно и по его id узнать?

Корректно рулить транзакциями - это я так понял грамотно ими управлять :)

И такой вот вопрос: Какие ограничения на размер базы/кол-во записей у IB?

← →
Sergey13 (2003-09-10 10:23) [47]

2HSolo © (09.09.03 14:12) [42]
>А о том, что не надо учить человека делать неправильно.
Почему не правильно. Тут это определение (правильно/неправильно) не подходит. Ты предлагаешь для лабы создать КИС класса ERP? Не получится, да и не надо этого. Цель этой лабы надо полагать научить студента пользоваться БД в Делфи, а не тонкости бух/складского учета освоить.

2Nick-From © (09.09.03 23:32) [46]
> но с Sergey13 всетки не согласен: пусть будет, возможно чуть сложнее реализовываться, но зато красиво, сделаешь и глаз радует :)
Да флаг в руки! Кто бы против был. Только вот нет предела совершенству. Я тебе могу еще например посоветовать подумать над многоуровневым справочником товаров - вообще красота. А сколько есть еще красивых штучек!!!

ЗЫ: Блокнот не хуже Ворда, он просто другой и для другого предназначен.

← →
HSolo (2003-09-10 10:46) [48]

> Jean © (09.09.03 20:40) [45]
Сам ты странный :)) Фирма состоит из одной кладовки? Или у каждого - кладовщика, менеджера, бухгалтера - своя программа, своя база, свой учет? Если второе - то это все хозяйство как-то согласуется? Или у Вас есть конкретный заказ, а остальное не Ваши проблемы? :))

> Nick-From © (09.09.03 23:32) [46]

> А при простом расчете остатка по какому-то товару разве запрос будет пробегать не по всей номенклатуре?

Нет (если, конечно, есть нужные индексы и если Вы не ищете по LIKE %text%). Пробегать будет по всему движению данного товара и по остатку до начала движения - если Вы ведете остатки.

> Или это Вы имеете ввиду то, что для МНОГИХ товаров придется внутри запроса рассчитывать остатки "на лету"

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

>>только добавить еще дату остатка - и вести ее триггерами
>Что значит "вести ее триггерами"? Типа все изменения в ней происходят через срабатывание триггеров на таблицах по приходу и расходу товаров?

Да, именно так. И править эту таблицу вручную не должен никто. Это для того, чтобы данные этой таблицы не расходились с данными приходных/расходных документов.

> зачем нужна дата в дополнительной таблице остатков? Ведь остаток товара можно и по его id узнать?

Бесспорно - если держать в этой таблице только текущие остатки. Тогда, кроме id товара, и в самом деле ничего не нужно. Но я имела в виду несколько другое - дополнительную таблицу остатков можно использовать для ускорения выдачи тех самых тяжелых отчетов, да и вообще остатка на любую дату. Схема такая: есть остатки по каждому товару на некую дату - обычно начало месяца, можно квартала, года... Чтобы узнать остаток товара на дату, мы находим в этой таблице остаток на дату, ближайшую к нужной, после чего просматриваем движение - но не все, а начиная с даты остатка. Но говорю сразу: эта система весьма громоздка и очень плохо реагирует на ввод/коррекцию документов задним числом - нужно пересчитывать все остатки после даты документа; я уж не говорю о самой процедуре расчета этих самых остатков на дату. Так что, прежде чем этой схемой воспользоваться, подумайте: стоит ли овчинка выделки, может, лучше пооптимизировать запросы.

> Корректно рулить транзакциями - это я так понял грамотно ими управлять :)

Да. Извините за жаргон.

> Какие ограничения на размер базы/кол-во записей у IB?

На ibase.ru в разделе downloads есть документация; то, что Вас интересует - в Operations Guide. Вообще, если Вы собираетесь работать с IB, очень рекомендую этот сайт.

← →
Nick-From (2003-09-10 14:44) [49]

tnx :)

← →
Jean (2003-09-22 13:46) [50]

2 HSolo. Действительно, есть конкретный заказ. Написать что-то вроде такой вот кладовки. Зачем мне заморачиваться и писать совершенно не нужные клиенту вещи. На мой взгляд, лучше сделать очень качественно и быстро именно то, что нужно.

← →
kaif (2003-09-22 14:32) [51]

2 Jean © (22.09.03 13:46) [50]
2 HSolo. Действительно, есть конкретный заказ. Написать что-то вроде такой вот кладовки. Зачем мне заморачиваться и писать совершенно не нужные клиенту вещи.

Не нужные клиенту вещи и вещи, котрые клиент считает ненужными суть разные понятия. Завтра клиент не примет программу, сказав, что "хорошо бы еще иметь вот это". А если ты скажешь, что это невозможно, так как " он сам сказал, что это не нужно", то он очень опечалится и скорее всего решит, что ты плохой программист. Клиенты всегда так решают, так как эта мысль проще, чем признать свою собственную недальновидность.
Возможно у тебя другой случай, но вероятность этого 1/100.

← →
Jean (2003-09-23 11:52) [52]

Че вы гоните, блин. Я просто поинтересовался чего да как для моей программы. Программа нужна маме. Она ведет один магазин. И ей нужно считать кол-во товара и суммы на конец месяца. И ничего больше не нужно.
Вероятность 1 процент :))))) Надо же и сработала :)))))

← →
kaif (2003-09-23 12:22) [53]

← →
MsGuns (2003-09-23 12:43) [54]

>kaif © (23.09.03 12:22) [53]
>Ну если мама, тогда другое дело. :)

Блин, а ведь с мамы можно было б и бабла рубануть,- для чада-то не пожалела б небось ;))

← →
Danilka (2003-09-23 12:45) [55]

[54] MsGuns © (23.09.03 12:43)
Только в том случае, если проходит через бухгалтерию. Иначе наоборот, никаких денег, в лучшем случае спасибо скажет. :)

← →
MsGuns (2003-09-23 13:41) [56]

>Danilka © (23.09.03 12:45) [55]
>>[54] MsGuns © (23.09.03 12:43)
>Только в том случае, если проходит через бухгалтерию. Иначе наоборот, никаких денег, в лучшем случае спасибо скажет. :)

Отнюдь..

← →
Jean (2003-09-23 16:26) [57]

Меня итак мама с папой кормят и одевают :)) так что брать денег за программу нехорошо >:-|

← →
MsGuns (2003-09-23 17:32) [58]

>Jean © (23.09.03 16:26) [57]
>Меня итак мама с папой кормят и одевают :)) так что брать денег за программу нехорошо >:-|

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

← →
Jean (2003-09-23 20:06) [59]

Нет, не поэтому, а потому, что все, что делаешь, надо делать хорошо, чтобы людям нравилось. А иначе работу не найдешь :( :)))

← →
Danilka (2003-09-24 08:22) [60]

← →
BIBOS (2003-09-27 10:49) [61]

Пиплс подскажите, что делать!

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

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