как посчитать остатки и обороти на складе, накладные товара и услуг вместе?

[bidzina]

Здравствуйте! Помогите пожалуйста найти оптимальное решение.
у меня есть рабочая программа(Сервер - Intebase 2009, Среда-Delphi XE6), которая работает уже 7 лет. Сначала база была проектирована для аптеки , но постепенно возникло потребление:
1) усовершенстовать Бизнес-процесс-Обобшать программу, сделать программой для учета не только лекарств,но и других тмц и, кроме этого, оказания услуг(например, для салонов красоти).
2) Переходить на Firebird 2.5, посколько из за отсутствия в Intebase 2009 derived tables и CTE мне было трудно, а иногда невозможно сделать какие-то запросы.

Новая база будет содержать около 60 таблиц, но пока в Firebird создана только основная часть, та "скелет", на который хочу обратить ваше внимание(это таблицы накладных(master и несколько datails, в которых по отдельности содержится записи приходов, расходов, списания, перемешения и услуг) и некоторые справочники.
приведу эту часть диаграммы:
http://i65.fastpic.ru/big/2014/1121/...d4ac49c81e.png

1) Как лучше посчитать остатки?. Я думаю о 2 вариантах:
а) создать дополнительные таблицы (operations,rests,storages,nomenkl) . для остатков на конкретный момент времени-сохранить в rests остатки,например, на начало месяца или квартала и потом пересчитать до "сегодня"? как написано здесь: http://www.sql.ru/forum/998443-6/osnovy-pr...d-v-2.(особенно 4-5 вариант).
Но при несколькиы складах отдельно для них хранить остатки конца каждого месяца значит, что около при 5000 наименовании в этом таблице через год будет 5000*12*количество складов записей! А через 5-10лет?!!!
б)создать "хранимые агрегаты", как прочитал в темах на форуме sql.ru? Но "хранимые агрегаты" создаются триггером а он сработает на before(after) insert, delete, update- то есть при каждом изменении таблиц документов происходит обновление записей в агрегате и так я получу текущие остатки. А для остатков 2 недельной давности "идти назад"? Или чего то не понимаю?

2) насколько оправдано то, что я загнал накладные товародвижения и услуг вместе,в одну таблицу? В услуге же будут свой, специфические поля, которые останутся пустыми для тмц? Не лучше ли ТМЦ и услуги(master tables) в отдельных таблицах?
3) Насколько оправдано собирать вместе накладные("шапки") приходов,расходов, перемещении и списания(на диаграмме не видно) в одну таблицу, сами datails - в отдельных таблицах? Или лучше так,как тут: http://www.sql.ru/forum/998443-6/osn...-v-2.(3-4-5 вариант)? Какие от этого могут быть "последствия" в будущем? Ведь у всех этих накладных будут свой, специфические поля, а эта значит избыточость данных и денормализация! Тем более, что постепенно появится "типичные" документы и других типов, например "обслуживание клиента своим материалом" или ""обслуживание материалом предприятия", или "документы инвентаризации", "кассовые операции прихода", "кассовые операции расхода " и т.д.? И у всех будут свои, дополнительные свойства и постепенно избыточность увеличится!
По вашему, даст собрание в одном таблице экономию времени во время запросов об остатках и оборотов? или есть еще другая причина за. Прощу ответьте аргументами.

С другой сторони, постепенно не соберутся ли много разных типов документов и поэтому написать запроси и собирать данные из многих datails таблиц не станет ли труднее, чем из одного? Кстати, в старом базе и "шапки" и datails у меня были в отдельных таблицах и на sql.ru и другие тоже посоветовали, что поскольку движение товара одно сущность, зачем его делить на части. Смотрите ссылку http://www.sql.ru/forum/1114585/vybo...sum-funkciyami и что там сибиряков советует:
я пишу: "Dimitry Sibiryakov, огромнейшее спасибо! проверил в Firebird 2.5 и все правильно работает, и разницу sum(income)-sum(sales) считывает.если можно еще один вопрос:что вы имели ввиду когда писали: "проще будет объединить эти две таблицы в одну"? я всегда думал что в целях нормализации БД sales и incomes объязательно дольжни быть в отдельных таблицах! "
Ответ:"И какую же нормальную форму ты пытаешься воплотить в жизнь разделяя одну сущность "движение средств" на две таблицы?.."

Сейчас уже в путанице, не пойму как поступить.

[Stilet]

Что бы ты не делал не надо создавать таблицы для остатков. Это не инвентаризация, а переход через период. Остатки ни в коем разе не должны вылезать отдельно от документов описывающих движение товаров.
Сейчас уже поздно, возможно я завтра тебе расскажу как происходит расчет товарооборота. Если не забуду, а пока что пройдись по форуму. Я тут уже расписывал схемы расчета товарно-складского учета хозяйства.

[bidzina]

Stilet! оба варианта активно поддерживаются на форумах.За 3 дня прочитал несколько тем по этой проблеме- как при достижении определенных объемов товарооборота запросы об остатках не начинали тормозить.
оба варианта обсуждают тут:
http://www.sql.ru/forum/647396-1/zapros-ostatkihttp://
http://www.sql.ru/forum/964534-1/hra...kirovok-recept
http://www.ibase.ru/devinfo/garbage.htm ("Хранимые агрегаты и динамическое обновление")
http://www.sql.ru/forum/998443-a/osn...ladskoy-bd-v-2
http://www.sql.ru/forum/1090117/nuzh...dskogo-uchyota
http://www.iblogmanager.com/download...h_Firebird.pdf

С нетерпением дождусь какой иной путь вы предложите!

[Stilet]

как при достижении определенных объемов товарооборота запросы об остатках не начинали тормозить.

А причем тут тормоза? Речь не о них. Будь у тебя хоть миллиард периодов СУБД это не уронит. Тут речь о том, что выделение остаточных ведомостей в отдельное... подразделение аукнется однажды тебе большим гальюном. Просто поверь, я уж поди года три варюсь в кипящем котле, которым мне любезно предоставили товарисчи-быдлокодеры из какой-то фирмы Орион-п что ли... В их недопрограмме остатки постоянно переписываются в отдельную таблицу, и когда происходит потеря (по каким-либо причинам) накладной в основной таблице остатки не всегда пересчитываются. В результате бугалтерская составляющая не может свести баланс. Выглядит это как будто ты 20 яблок разделил между холодильниками, а твой старший брат не зная этого таскает их только из первого, но ты об этом ни слуху ни духу. Представь что ты подумаешь открыв однажды холодильник в надежде достать морозненькое вкусное яблочко а там... мышь повесилась.

Повторял, повторяю и буду повторять - остатки ни в коем разе не должны храниться, они должны расчитываться
Ты конечно можешь построить схему товарооборота как тебе хочется на твоем предприятии, но поверь, чем проще она будет тем стабильнее будет работать.
Всю информацию и о движении и плановые и отчетные показатели можно будет подчерпнуть из внесенных накладных, а больше тебе ничего и не потребуется.
Вот по ссылке что ты приложил (http://www.sql.ru/forum/998443-a/osn...ladskoy-bd-v-2) внимания заслуживает только первая схема.
Вариант 2 и 3 это больная выдумка того, кто ни разу со складами не работал.
Это усовершенствование гемоороя, не более.

Вот мои соображения, высказанные ранее:
http://www.programmersforum.ru/showthread.php?t=217650
http://www.programmersforum.ru/showthread.php?t=199947
http://www.programmersforum.ru/showthread.php?t=198706
http://www.programmersforum.ru/showthread.php?t=235101

[bidzina]

Сообщение от Stilet

Вот по ссылке что ты приложил (http://www.sql.ru/forum/998443-a/osn...ladskoy-bd-v-2) внимания заслуживает только первая схема.
Вариант 2 и 3 это больная выдумка того, кто ни разу со складами не работал.
Это усовершенствование гемоороя, не более.

Stilet, что вы имеете в виду, по вашему лучше документи приходов,расходов, перемещении,списания,услуг объединить в общей таблице?

[Аватар]

По моему тоже лучше и надежней остатки на весу и все движение в одной таблице

[Stilet]

объединить в общей таблице?

Именно так. Поскольку все эти документы все равно будут иметь одну и ту же структуру. По крайней мере в твоей лабе.

[bidzina]

Сообщение от Аватар

По моему тоже лучше и надежней остатки на весу и все движение в одной таблице

Аватар, причину,зачем не хочу, чтобы они были вместе, в одном таблице, я уже сказал: "Ведь у всех этих накладных будут свой, специфические поля, а эта значит избыточость данных и денормализация! Тем более, что постепенно появится "типичные" документы и других типов, например "обслуживание клиента своим материалом" или ""обслуживание материалом предприятия", или "документы инвентаризации", "кассовые операции прихода", "кассовые операции расхода " и т.д.? И у всех будут свои, дополнительные свойства!" Вот об этом идёт разговор!

Сообщение от Stilet

Именно так. Поскольку все эти документы все равно будут иметь одну и ту же структуру. По крайней мере в твоей лабе.

Stilet, причину,зачем не хочу, чтобы они были вместе, в одном таблице, я уже сказал: "Ведь у всех этих накладных будут свой, специфические поля, а эта значит избыточость данных и денормализация! Тем более, что постепенно появится "типичные" документы и других типов, например "обслуживание клиента своим материалом" или ""обслуживание материалом предприятия", или "документы инвентаризации", "кассовые операции прихода", "кассовые операции расхода " и т.д.? И у всех будут свои, дополнительные свойства!" Вот об этом идёт разговор!

[Аватар]

Ну и ладушки, ток я потом посмотрю как вы всю эту халабуду будете запросами в одну кучу собирать для оборотов и сальдовок

[Stilet]

причину,зачем не хочу, чтобы они были вместе, в одном таблице, я уже сказал

Ты путаешь механизм хранения с механизмом обработки.
Ты можешь держать эти накладные а точнее их содержимое в неких других таблицах, даже в БЛОБ полях. Речь идет о консолидации документов в едином реестре, а не о их обработке.

Тем более, что постепенно появится

Что такое масштабируемость приложений ты знаешь?
Вот тебе стоит это продумать, поскольку сколько бы ты не насоздавал таблиц, как бы не развел данные по разным углам, если у тебя что-то меняется в структуре документации это будет отражаться на всей базе.
Опять таки интересный момент: Раз у всех накладных будут разные поля то получается на одну накладную придется создавать каждый раз отдельную таблицу.
Короче ты тупо приведешь свое ПО к совершенно неработоспособному виду.
Выдели из всех накладных общие поля, остальные храни в BLOB виде как дополнительную информацию.
Иначе тебе нужно брать иерархическую СУБД типа Cashe или Lotus, где нет зависимости от структуры.