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

← →
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]

2 Jean © (23.09.03 11:52) [52]
Ну если мама, тогда другое дело. :)
Мне бы таких заказчиков...

← →
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)
Только в том случае, если проходит через бухгалтерию. Иначе наоборот, никаких денег, в лучшем случае спасибо скажет. :)

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

Отнюдь..

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

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

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

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

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

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

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

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