| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Избежание переполнения таблиц [D6, IB5.x, IB6.x]
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. цена, по которой продали
Когда товар приходит на склад, в таблицу товаров добавляются соответствующие записи, в таблицу приходных накладных также добавляются записи со ссылками на добавленные записи товаров.
Когда товар списываем со склада, в таблице товаров меняется текущее кол-во товаров, в таблицу расходных накладных также добавляются записи со ссылками на проданные товары.
Проблема в том, что даже когда товар полностью продан и его на складе уже нет, его нельзя удалить из таблицы товаров, т.к. на него ссылаются расходные и приходные накладные. Получается, что таблица будет постоянно пополняться (да и таблицы накладных тоже), что в конце концов со временем будет тормозить базу.
Мастера, подскажите, как решить, можт по-другому организовать таблицы как-то? Два дня вот соображаю - никак. Или это и не страшно, что нет удаления, хотя навряд-ли.
BIBOS (2003-09-27 10:49:00) [1]
Пиплс подскажите, что делать!
У меня у друга GrossBee. А недавно говорит начала тормозить, дольше проводит и другие операции тоже выполняет медленее.
Подскажите плзз возможные причины и варианты их устранения.
Danilka (2003-09-24 08:22:00) [2]
MsGuns ©
Хе-хе, я знал, что за эту работу не заплатят деньгой - сам писал для маминой бухгалтерии в институте. :))
Jean (2003-09-23 20:06:00) [3]
Нет, не поэтому, а потому, что все, что делаешь, надо делать хорошо, чтобы людям нравилось. А иначе работу не найдешь :( :)))
MsGuns (2003-09-23 17:32:00) [4]
>Jean © (23.09.03 16:26) [57]
>Меня итак мама с папой кормят и одевают :)) так что брать денег за программу нехорошо >:-|
Поэтому ты, как дармоед, должен расстараться в пух и перья и сваять чудо чудное, а не топором рубить и соплями склеивать по принципу "абы було".
Jean (2003-09-23 16:26:00) [5]
Меня итак мама с папой кормят и одевают :)) так что брать денег за программу нехорошо >:-|
MsGuns (2003-09-23 13:41:00) [6]
>Danilka © (23.09.03 12:45) [55]
>>[54] MsGuns © (23.09.03 12:43)
>Только в том случае, если проходит через бухгалтерию. Иначе наоборот, никаких денег, в лучшем случае спасибо скажет. :)
Отнюдь..
Danilka (2003-09-23 12:45:00) [7]
[54] MsGuns © (23.09.03 12:43)
Только в том случае, если проходит через бухгалтерию. Иначе наоборот, никаких денег, в лучшем случае спасибо скажет. :)
MsGuns (2003-09-23 12:43:00) [8]
>kaif © (23.09.03 12:22) [53]
>Ну если мама, тогда другое дело. :)
Блин, а ведь с мамы можно было б и бабла рубануть,- для чада-то не пожалела б небось ;))
kaif (2003-09-23 12:22:00) [9]
2 Jean © (23.09.03 11:52) [52]
Ну если мама, тогда другое дело. :)
Мне бы таких заказчиков...
Jean (2003-09-23 11:52:00) [10]
Че вы гоните, блин. Я просто поинтересовался чего да как для моей программы. Программа нужна маме. Она ведет один магазин. И ей нужно считать кол-во товара и суммы на конец месяца. И ничего больше не нужно.
Вероятность 1 процент :))))) Надо же и сработала :)))))
kaif (2003-09-22 14:32:00) [11]
2 Jean © (22.09.03 13:46) [50]
2 HSolo. Действительно, есть конкретный заказ. Написать что-то вроде такой вот кладовки. Зачем мне заморачиваться и писать совершенно не нужные клиенту вещи.
Не нужные клиенту вещи и вещи, котрые клиент считает ненужными суть разные понятия. Завтра клиент не примет программу, сказав, что "хорошо бы еще иметь вот это". А если ты скажешь, что это невозможно, так как " он сам сказал, что это не нужно", то он очень опечалится и скорее всего решит, что ты плохой программист. Клиенты всегда так решают, так как эта мысль проще, чем признать свою собственную недальновидность.
Возможно у тебя другой случай, но вероятность этого 1/100.
Jean (2003-09-22 13:46:00) [12]
2 HSolo. Действительно, есть конкретный заказ. Написать что-то вроде такой вот кладовки. Зачем мне заморачиваться и писать совершенно не нужные клиенту вещи. На мой взгляд, лучше сделать очень качественно и быстро именно то, что нужно.
Nick-From (2003-09-10 14:44:00) [13]
tnx :)
HSolo (2003-09-10 10:46:00) [14]
> 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, очень рекомендую этот сайт.
Sergey13 (2003-09-10 10:23:00) [15]
2HSolo © (09.09.03 14:12) [42]
>А о том, что не надо учить человека делать неправильно.
Почему не правильно. Тут это определение (правильно/неправильно) не подходит. Ты предлагаешь для лабы создать КИС класса ERP? Не получится, да и не надо этого. Цель этой лабы надо полагать научить студента пользоваться БД в Делфи, а не тонкости бух/складского учета освоить.
2Nick-From © (09.09.03 23:32) [46]
> но с Sergey13 всетки не согласен: пусть будет, возможно чуть сложнее реализовываться, но зато красиво, сделаешь и глаз радует :)
Да флаг в руки! Кто бы против был. Только вот нет предела совершенству. Я тебе могу еще например посоветовать подумать над многоуровневым справочником товаров - вообще красота. А сколько есть еще красивых штучек!!!
ЗЫ: Блокнот не хуже Ворда, он просто другой и для другого предназначен.
Nick-From (2003-09-09 23:32:00) [16]
Да, возьмите меня к себе работать ;) только через год :)) по окончании института =)
Конечно схемы бд были приведены очень даже ничего, большинство бухгалтерских изощрений я так и не просек еще, но с Sergey13 всетки не согласен: пусть будет, возможно чуть сложнее реализовываться, но зато красиво, сделаешь и глаз радует :)
(Я кладу на другие предметы :)) )
А если серьезно, то такие вот вопросы есть исчо:
2 HSolo © (08.09.03 16:28)
> Но в случае тяжелой выборки (типа оборотной ведомости по всей >номенклатуре за достаточно большой промежуток времени) может >изрядно падать скорость.
А при простом расчете остатка по какому-то товару разве запрос будет пробегать не по всей номенклатуре? Или это Вы имеете ввиду то, что для МНОГИХ товаров придется внутри запроса рассчитывать остатки "на лету" и это будет причиной тормозов, нежели просто выборка из дополнительной таблицы?
и исчо:
>только добавить еще дату остатка - и вести ее триггерами
Что значит "вести ее триггерами"? Типа все изменения в ней происходят через срабатывание триггеров на таблицах по приходу и расходу товаров?
и исчо:
Чего-то не понял зачем нужна дата в дополнительной таблице остатков? Ведь остаток товара можно и по его id узнать?
Корректно рулить транзакциями - это я так понял грамотно ими управлять :)
И такой вот вопрос: Какие ограничения на размер базы/кол-во записей у IB?
Jean (2003-09-09 20:40:00) [17]
> HSolo: Странный ты. Если кладовщик просит программу, почему я должен делать ее еще и на бухгалтеров, менеджеров и др. персонал, которого может и в кладовке-то нету???!!!
kaif (2003-09-09 19:41:00) [18]
Я в своей системе 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 запросом. Ни один запрос не длится больше долей секунды. Будь то остатки, стоимости или еще чего.
MsGuns (2003-09-09 16:53:00) [19]
>HSolo © (09.09.03 14:12) [42]
>А о том, что не надо учить человека делать неправильно. Ваши же слова
Ну, говорить прописные истины - много ума не нужно ;))
Так ведь все равно учили, учат и будут учить ! И с этим ничего не поделаешь. Но хотеть, как говорится, не вредно.
HSolo (2003-09-09 14:12:00) [20]
> MsGuns © (09.09.03 13:29) [40]
Уговорили :) Пусть к Вам приходит :)) И ко мне придет - научу, куда ж я денусь... Не об этом речь. А о том, что не надо учить человека делать неправильно. Ваши же слова :))
| |
Страницы: 