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

Новая база содержит около 60 таблиц, но основная часть, на который хочу обратить ваше внимание ,это таблицы накладных(master) и несколько datails, в которых по отдельности содержится записи приходов, расходов, списания, перемешения и услуг.
приведу эту часть диаграммы:


Главные вопросы и сложности у меня такие:
1) Насколько оправдано то, что я собирал вместе накладные("шапки") приходов,расходов, перемещении и списания (на диаграмме не видно) в одну таблицу? Какие от этого могут "отрицательные последствия" в будущем? У всех этих накладных будут свой, специфические поля, а эта значит избыточость данных и денормализация! Тем более, что постепенно появится "типичные" документы и других типов, например "обслуживание клиента своим материалом" или ""обслуживание материалом предприятия", или "документы инвентаризации", "кассовые операции прихода", "кассовые операции расхода " и т.д.? И у всех будут свои, дополнительные свойства и постепенно избыточность увеличится!
По вашему, даст собрание в одном таблице экономию времени во время запросов об остатках и оборотов? или есть еще другая причина за. Прощу ответьте аргументами.
2) По той же причине насколько оправдано то, что я загнал накладные товародвижения и услуг вместе ,в одну таблицу? В услуге же будут свой, специфические поля, которые останутся пустыми для тмц? Не лучше ли ТМЦ и услуги(master tables) в отдельных таблицах?
3) Как лучше посчитать остатки?
а) создать таблицу проводок(операции), как написано здесь: http://www.sql.ru/forum/998443-6/osnovy-proektirovaniya-skladskoy-bd-v-2. Но при несколькиы складах отдельно для них хранить остатки конца каждого месяца значит, что около при 5000 наименовании в этом таблице через год будет 5000*12*количество складов записей! А через 5-10лет?!!!
б) В старом базе я решил эту проблему так: при каждом прыходе, в записях прыхода кроме qty сохранял и rest(динамические остатки): а при продаже 25 шт в записях прихода программно менял остатки(при методе FIFO):
суммируя sum(rest) получал динамические остатки(=75шт)! Таким путем и партионный учет получился! (Конечно, rest менял в рамках одной транзакции.)
Но проблема в том, что так я получал только текущие остатки , а старые остатки и обороты всё равно считал с помощью не так уж быстрых запросов. Запросы начинали особо тормозить при работе в сети. Интересно ваше мнение, есть у кого-нибудь другое решение для более быстрого получения остатков и оборотов?

4) И последний вопрос-Эта диаграмма не сопротивляеться ли с возможностью в будущем создать в базе таблицу бухгалтерских счетов и расширять простим бухгалтерским учетом? Или снова придется перепроектировать базу данных?

Davidkokoмне было трудно, а иногда невозможно сделать какие-то запросы.
Dimitry SibiryakovЭто явное свидетельство, что БД была спроектирована несоответствующим образом.

Dimitry Sibiryakov. смотрите здесь: http://www.sql.ru/forum/1114585/vyborka-dannyh-iz-2-svyazannyh-tablic-s-neskolkimi-sum-funkciyami?hl=
1. Как видите,на счет того, что причиной может бить derived tables я от вас узнал 2. там видно запрос и что Interbase 2009 возвращает. а тот же запрос в Firebird 2.5.3 отбирает правильные записи из БД. 3. На других форумах тоже никто не смог помочь и посоветовали Firebird. Но главное не это, я окончательно перепроектирую базу на Firebid. Сейчас у меня вопроси совсем другого направления.

Dimitry Sibiryakov, можете смотреть и здесь: http://stackoverflow.com/questions/25710347/2-sum-functions-from-2-different-tables-in-1-select-statement-whats-wrong

Dimitry SibiryakovНа что смотреть? На то, что я тебе там пальцем ткнул в ошибку проектирования БД
Я не понял, где вы нашли ошибку проектирования БД?

Dimitry SibiryakovА ещё я там тебе дал ссылку на статью о методах доступа к данным.

Извините но нету там ссылки о методах доступа к данным

Dimitry SibiryakovА ещё я могу дать ссылку на себя, любимого:
http://www.sql.ru/forum/964534/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept?hl=

а за эту ссылку, конечно,спасибо!

DavidkokoИзвините но нету там ссылки о методах доступа к данным
Dimitry SibiryakovДа ну? А это 16670647 что?..
Dimitry Sibiryakov, я не прочитал эту ссылку потому, что в quot-е написано des1roer и думал , что принадлежал ему. Спасибо! Сейчас прочту. А на счет моих других вопросов?
В том теме вы мне писали: "проще будет объединить эти две таблицы в одну". вы подразумевали объединить master tables (накладные приходов-расходов или datails(записи) тоже ?

Dimitry Sibiryakov, интересно ваше мнение на счет
1) того, что я загнал накладные товародвижения и услуг вместе ,в одну таблицу?
2) что вы думаете о моем методе посчитания текущих остатков [B]суммированием остатков каждой партии прихода?[/]

Здравствуйте! Если можете объясните,пожалуйста, в теме Dimitry Sibiryakov-а "Хранимые агрегаты без конфликтов и блокировок - рецепт" http://www.sql.ru/forum/964534-a/hranimye-agregaty-bez-konfliktov-i-blokirovok-recept, мы получаем текущие остатки, правильно?
На этом форуме иногда спрашивают, что у них для быстрой выборки остатков/оборотов есть дополнительные таблицы(Rests), где в конце месяца, например, добавляют текущие остатки и потом с этих остатков считают новые остатки на каждый момент времени(+ приход/-расход),и что у них запроси для получения остатков/оборотов по возрастанию размеров БД постепенно замедляются, им предлагают использовать хранимые агрегаты. Может быть я не понял,но если я не сохраню остатки каждого товара на каждый момент времени , как получу из хранимых агрегатов остатки которые были в базе,например,2 месяца назад? Ведь хранимые агрегаты дают текущие остатки. или я что-то путаю?