|
|
Регистрация | << Правила форума >> | FAQ | Пользователи | Календарь | Поиск | Сообщения за сегодня | Все разделы прочитаны |
|
Опции темы | Поиск в этой теме | Опции просмотра |
|
#1
|
|||
|
|||
таблицы прихода-расхода вместе или отдельно, остатки и обороти
Здравствуйте! Помогите пожалуйста найти оптимальное решение.
у меня есть рабочая программа(Сервер - Intebase 2009, Среда-Delphi XE6). Сначала база была проектирована для аптеки,но постепенно возникло потребление: 1) усовершенстовать Бизнес-процесс- сделать программой для учета не только лекарств,но и других тмц и, кроме этого, оказания услуг. 2) Переходить на Firebird 2.5.3. Новая база содержит около 60 таблиц, но основная часть, на который хочу обратить ваше внимание ,это одна, общая таблица документов(master) и несколько datails, в которых по отдельности содержатся записи приходов, расходов, списания, перемешения и услуг. приведу эту часть диаграммы: http://i65.fastpic.ru/big/2014/1121/...d4ac49c81e.png у меня 2 вопроса: 1)Как лучше посчитать остатки? а) создать дополнительные таблицы (operations,rests,storages,nomenkl) . для остатков на конкретный момент времени-сохранить в rests остатки,например, на начало месяца или квартала и потом пересчитать до "сегодня"? как написано здесь: http://www.sql.ru/forum/998443-6/osn...-v-2.(особенно IV-V вариант). Но при несколькиы складах отдельно для них хранить остатки конца каждого месяца значит, что около при 5000 наименовании в этом таблице через год будет 5000*12*количество складов записей! А через 5-10лет?!!! б)создать "хранимые агрегаты", как прочитал в темах на форуме sql.ru. Но "хранимые агрегаты" создаются триггером а он сработает на before(after) insert, delete, update- то есть при каждом изменении таблиц документов происходит обновление записей в агрегате и так я получу текущие остатки. 2) Насколько оправдано то, что я собирал вместе накладные("шапки") приходов,расходов, перемещении и списания в одну таблицу? У всех этих накладных будут свой, специфические поля, а эта значит избыточость данных и денормализация! Тем более, что постепенно появится "типичные" документы и других типов, например "обслуживание клиента своим материалом" или ""обслуживание материалом предприятия", или "документы инвентаризации", "кассовые операции прихода", "кассовые операции расхода " и т.д.? И у всех будут свои, дополнительные свойства и постепенно избыточность увеличится! По вашему, даст собрание в одном таблице экономию времени во время запросов об остатках и оборотов? или есть еще другая причина за. Прощу ответьте аргументами. У кого какой опить сохранения текущих остатков, прощу поделитесь. Последний раз редактировалось davidkoko, 25.11.2014 в 19:53. |
#2
|
|||
|
|||
здесь никого нет дома?
|
#3
|
||||
|
||||
Цитата:
Слишком глобальная постановка вопроса, разбейте задачу на меньшие куски и тогда вопрошайте о решении с конкретным кодом. Эта "рабочая программа" в смысле непонятный баз с его архитектурой, слвбг есть только у вас З.Ы. Здесь кстати есть раздел "Работа", можете и не мучаться особо обратившись туда Я не понял Вашего вопроса, но всё же Вам на него отвечу! |
#4
|
|||
|
|||
особо не разбираюсь,
касаемо избыточности/специфичности тут (видео про Subtypes вроде) видел что можно делать дополнительную таблицу с теми же значениями индекса, какие у этого последствия не знаю а вобще да, tldr >woweook< |
#5
|
|||
|
|||
Цитата:
Pyro, хотя видео не то, но интересное. спасибо. а на счет tldr, уже отредактировал |
#6
|
|||
|
|||
Цитата:
Alegun я не думаю, что человек, который ищет оптимальный путь для сохранения остатков и пока не решил создать дополнительные таблицы для остатков или "хранимые агрегаты" должен идти в раздел "Работа"! |
#7
|
||||
|
||||
Цитата:
Не стоит путать форумы с богадельнями. © Bargest |
#8
|
|||
|
|||
Цитата:
Я не боюсь размеров БД, я сейчас перестраиваю схему старой БД и хочу так построить, чтобы через 1-2 года снова не пришлось изменить. поэтому хочу такую схему реализовать, чтобы при достижении определенных объемов товарооборота запросы об остатках и оборотах не начинали тормозить. Поэтому у меня 2 вопроса: 1) Как лучше посчитать остатки, без тормозов?. надо создать дополнительную таблицу rests для остатков на конкретный момент времени и сохранить в rests остатки и в запросах выборку остатков должны делать по ним,например, на начало месяца или квартала и потом пересчитать до "сегодня"? как написано здесь: http://www.sql.ru/forum/998443-6/osn...-v-2.(особенно IV-V вариант). Это,конечно, большой шаг вперед, чем вообще не создать таблицу остатков,но... дело в том, что и в этом случае через некоторое время, когда в БД накопится очень много записей документов, запроси все равно замедляются (много таких тем видел на SQL.RU) и,поэтому, KDV, Dimitry Sibiryakov и др.советуют "хранимые агрегаты", которые создаются триггером и срабативают на before(after) insert, delete, update. http://www.sql.ru/forum/964534-1/hra...kirovok-recept http://www.iblogmanager.com/download...h_Firebird.pdf 2) Насколько оправдано собирать вместе накладные("шапки") приходов,расходов, перемещении, списания и ещё других выдов в одну таблицу(Doc),а сами datails(табличные части) - в отдельных таблицах? Или лучше так,как тут: http://www.sql.ru/forum/998443-6/osn...-v-2. (III-IV-V вариант)? Какие от этого могут быть "последствия" в будущем? Ведь у всех этих накладных будут свой, специфические поля, а эта значит избыточость данных и денормализация! Тем более, что постепенно появится "типичные" документы и других типов, например "обслуживание клиента своим материалом" или ""обслуживание материалом предприятия", или "документы инвентаризации", "кассовые операции прихода", "кассовые операции расхода " и т.д.? И у всех будут свои, дополнительные свойства и постепенно избыточность увеличится! Выборка из многих таких таблиц всякими Union All-ом не замедлит выборку и собирать данные из многих datails таблиц не станет ли труднее, чем из одного(смотрите таблица Doc на рисунке)? Кстати, в старом базе и "шапки" и datails у меня были в отдельных таблицах и на sql.ru и другие тоже посоветовали, что поскольку движение товара одно сущность, зачем его делить на части. Смотрите ссылку http://www.sql.ru/forum/1114585/vybo...sum-funkciyami и что там сибиряков советует: я пишу: "Dimitry Sibiryakov, огромнейшее спасибо! проверил в Firebird 2.5 и все правильно работает, и разницу sum(income)-sum(sales) считывает.если можно еще один вопрос:что вы имели ввиду когда писали: "проще будет объединить эти две таблицы в одну"? я всегда думал что в целях нормализации БД sales и incomes объязательно дольжни быть в отдельных таблицах! " Ответ:"И какую же нормальную форму ты пытаешься воплотить в жизнь разделяя одну сущность "движение средств" на две таблицы?.." Последний раз редактировалось davidkoko, 26.11.2014 в 18:49. |
#9
|
||||
|
||||
Цитата:
Цитата:
А в деле хранения остатков я бы посоветовал опереться на бизнес-процессы. Как часто проводится инвентаризация? Взять ее за точку отсчета и пересчитывать приход/расход на за весь период, а с момента последней инвентаризации. Про шапки не понял. Не нужно тут дублировать одно и то же по несколько раз, писать в стиле SQL.ru и давать на него ссылки. Разбейте ваше повествование на осмысленные предложения и абзацы. Не стоит путать форумы с богадельнями. © Bargest |
#10
|
|||
|
|||
Цитата:
Эта будет таблица только для остатков . Никто не говорит что все запроси сделать из этих таблиц, только запроси об остатках/оборотах, по причине быстрой выборки. Цитата:
Цитата:
Последний раз редактировалось davidkoko, 26.11.2014 в 19:26. |