[davidkoko]

Здравствуйте! Помогите пожалуйста найти оптимальное решение.
у меня есть рабочая программа(Сервер - 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]

здесь никого нет дома?

[Alegun]

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

здесь никого нет дома?

Ага точно, there is nobody at home, просто все сразу побежали впо библиотекам и гугелям чтоб ваше потребление решить, усилено начали этот прог Обобшать

Слишком глобальная постановка вопроса, разбейте задачу на меньшие куски и тогда вопрошайте о решении с конкретным кодом. Эта "рабочая программа" в смысле непонятный баз с его архитектурой, слвбг есть только у вас

З.Ы. Здесь кстати есть раздел "Работа", можете и не мучаться особо обратившись туда

[Pyro]

особо не разбираюсь,
касаемо избыточности/специфичности тут (видео про Subtypes вроде) видел что можно делать дополнительную таблицу с теми же значениями индекса, какие у этого последствия не знаю
а вобще да, tldr

[davidkoko]

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

Ага точно, there is nobody at home, просто все сразу побежали впо библиотекам и гугелям чтоб ваше потребление решить, усилено начали этот прог Обобшать

Слишком глобальная постановка вопроса, разбейте задачу на меньшие куски и тогда вопрошайте о решении с конкретным кодом. Эта "рабочая программа" в смысле непонятный баз с его архитектурой, слвбг есть только у вас

З.Ы. Здесь кстати есть раздел "Работа", можете и не мучаться особо обратившись туда

Alegun я не думаю, что человек, который ищет оптимальный путь для сохранения остатков и пока не решил создать дополнительные таблицы для остатков или "хранимые агрегаты" должен идти в раздел "Работа"!

[davidkoko]

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

особо не разбираюсь,
касаемо избыточности/специфичности тут (видео про Subtypes вроде) видел что можно делать дополнительную таблицу с теми же значениями индекса, какие у этого последствия не знаю
а вобще да, tldr

Pyro, хотя видео не то, но интересное. спасибо.
а на счет tldr, уже отредактировал

[Freeman]

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

будет 5000*12*количество складов записей! А через 5-10лет?!!!

База данных -- не массив, не нужно этого бояться. Сначала обязательно должны быть индексы, эффективность которых должна подтверждаться планом выполнения. В будущем, когда данных станет сильно больше, на помощь придет кластеризация или секционирование.

[davidkoko]

База данных -- не массив, не нужно этого бояться. Сначала обязательно должны быть индексы, эффективность которых должна подтверждаться планом выполнения. В будущем, когда данных станет сильно больше, на помощь придет кластеризация или секционирование.

Freeman Встроенной поддержки кластеризации у Firebird нет.
Я не боюсь размеров БД, я сейчас перестраиваю схему старой БД и хочу так построить, чтобы через 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 объязательно дольжни быть в отдельных таблицах! "
Ответ:"И какую же нормальную форму ты пытаешься воплотить в жизнь разделяя одну сущность "движение средств" на две таблицы?.."

[Freeman]

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

Встроенной поддержки кластеризации у Firebird нет.

Да, момент использования Firebird я упустил. Что же, с ростом бизнеса будет повод купить новый сервер или перейти на более продвинутую СУБД.

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

Я не боюсь размеров БД, я сейчас перестраиваю схему старой БД и хочу так построить, чтобы через 1-2 года снова не пришлось изменить.

Через 1-2 года может измениться сам бизнес, который вы автоматизируете, что есть изменение постановки задачи. Если вы штатный автоматизатор или работаете на длинном контракте, в условиях начавшегося кризиса советую не заглядывать слишком далеко. Уже работающее медленное решение лучше, чем летающее, но завтра.

А в деле хранения остатков я бы посоветовал опереться на бизнес-процессы. Как часто проводится инвентаризация? Взять ее за точку отсчета и пересчитывать приход/расход на за весь период, а с момента последней инвентаризации.

Про шапки не понял. Не нужно тут дублировать одно и то же по несколько раз, писать в стиле SQL.ru и давать на него ссылки. Разбейте ваше повествование на осмысленные предложения и абзацы.

[davidkoko]

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

А в деле хранения остатков я бы посоветовал опереться на бизнес-процессы. Как часто проводится инвентаризация? Взять ее за точку отсчета и пересчитывать приход/расход на за весь период, а с момента последней инвентаризации.

То, что остатки надо получить из документов прихода/расхода, это все знают. Я уже объяснял для чего дополнительные таблицы остатков или "хранимые агрегаты". дело в том, что через некоторое время, когда в БД накопится очень много записей документов, запроси, основанные на первичные документы прихода/расхода, все равно замедляются (много таких тем видел на SQL.RU и на других сайтах). А выход из этой ситуации описан тут: http://www.sql.ru/forum/998443-6/osn...-v-2.(особенно IV-V вариант).
Эта будет таблица только для остатков . Никто не говорит что все запроси сделать из этих таблиц, только запроси об остатках/оборотах, по причине быстрой выборки.

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

Про шапки не понял.

Doc-таблица накладных приходов/расходов-то есть master table(шапкой еще называют), а Docin,Docout,DocServ- подчинённые таблицы(Datail tables) для записей. конкретно: Docin- для записей в накладной прихода, Docout-записи в накладной прихода, DocServ-записи в накладной услуг.

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

Не нужно тут дублировать одно и то же по несколько раз

Когда ясно всё написано и все равно вопросы,придётся "дублировать"

[Freeman]

Не вижу реакции на мое предложение об опоре на инвентаризацию.

[davidkoko]

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

Не вижу реакции на мое предложение об опоре на инвентаризацию.

Freeman,Я же сказал:"То, что остатки надо получить из документов прихода/расхода, это все знают". А как получу остатки из документов прихода/расхода, если не так: количество последней инвентаризации+sum(колич.прихода)-sum(колич.расхода). Это и так подразумевается!
Но я хочу получить остатки по другому- как описано в линке.

[Freeman]

Тогда я совсем потерял квалификацию в учете ТМЦ со своим компилятором. Пусть кто-нибудь из старших товарищей ответит.

[davidkoko]

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

Тогда я совсем потерял квалификацию в учете ТМЦ со своим компилятором. Пусть кто-нибудь из старших товарищей ответит.

Нет, дело не в квалификации, просто такой способ выборки данных(то есть из дополнительно созданных таблиц ) тоже существует и пользуются тогда, когда БД очень растолстеет и запроси выполняются медленнее.

[Alegun]

Оффтоп: Сначало думал что это обычная ошибка, но такое повторяется - что означает глагол "запроси"?

Что-то кстати не вижу я здесь БД - из приведённых параметров выходит что это вовсе не база, а обычное хранилище архивных документов.
"То, что остатки надо получить из документов прихода/расхода, это все знают" - ну так и надо делать, а не хранить во всё разбухающей отдельной таблице константный результат, который и так уже не изменить, непонятки