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