Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Алгоритмика триггера [D6, IB6.x]

MsGuns © (2003-02-21 12:10:00)
Добрый день и с наступающим праздником настоящих мужчин, а следовательно, и мастаков !

Объект.
Есть материальные документы приходно-расходного типа. В фактуре документа по каждой строке имеется Кол-во, Цена, Сумма.
Для приходов калькуляция:
1. ЦЕНА = Сумма/Кол-во
Для расхода -
2. СУММА = Кол-во*Цена

Способы реализации.

I. БД сводная, т.е. и для приходов и для расходов - одни и те же таблицы (заголовки+фактура). Триггер построен так, что в зависимости от типа документа выбирает способ вычисления.

II. БД разбита на 2 пары таблиц (для приходов и расходов)
Триггеры обеих детал-таблиц работают без ветвления, "жестко".

Как, с точки зрения культуры розработки серверной части БД грамотнее делать проектирование и реализацию бизнес-логики ? И насколько влияет на производительность выборок факт одной большой таблицы или двух поменьше ?

Вопрос возник в связи с нехваткой практического опыта работы с серверными БД.

Заранее благоларен всем пожелавшим поделиться опытом.

fool (2003-02-21 15:48:00) [1]
>MsGuns © (21.02.03 14:50)
По плюсам:
1. Несомненно, чем больше потомков, тем очевидней будет выигрыш в скорости. Но это будет заметно при большом объеме данных и(или) при большой загруженности сервера
2. При сложной логике взаимодействия между сущностями (особенно если взаимодействие существенно различаеться в ветках "приход" и "расход") это может оказаться весьма немаловажным.

По минусам:
1. Этот минус неочевиден, т.к. естественно потребуеться некоторое увеличение внимания, чтоб везде где надо "наштамповать" представления или ХП в двойном количестве, но при сложной логике взаимодействия сами ХП, триггера и т.д. скорее всего будут гораздо "прозрачнее".
2. Не думаю, что загруженность сервера "служебной" информацией при двух ветвях будет существеннее больще, чем при одной.

Итог:
При относительно небольших объемах хранимой информации я бы пошел по пути 1 (не думаю, что взаимодействия между сущьностями настолько сложны, чтоб только ради их упрощения ийти на разбиение). Если и объемы велики и отношения сложны, я бы наверное выбрал 2. Увеличение работы компенсировалось бы "прозрачностью" триггеров, ХП и т.д. и улучшением скоростных характеристик.
Но Вам "со своей колокольни" виднее, де и опыта, я думаю, поболее будет.

Desdechado (2003-02-21 15:35:00) [2]
я б ориентировался на типичные запросы, которые возникают.
1. если они в основном работают по двум сущностям, то логичнее хранить в одной таблице
2. если преобладают раздельные, то и хранить порознь - все-таки разные штуки хранишь

MsGuns (2003-02-21 14:50:00) [3]
Дело в том, что помимо фактур у документов есть еще "потомки":
динамика оплаты, статисика коррекций и т.д. Т.е. получается, что деление всего семейства "Документы" на физические группы таблиц (пример - расход,приход) фактически удваивает число таблиц и их метаданных (генераторов, представлений, триггеров и т.п.)

При этом плюсы :
1. Уменьшение объемов данных в каждой таблице и, как следствие, ожидание повышения скорости выборок (особенно если учесть, что таблицы, особенно фактура, весьма "нагруженны", т.е. содержат немалое кол-во доменов (полей), среди которых есть и BLOB.
2. Четко прописанное однозначное "поведение" элементов метаданных каждой таблицы (триггеров например), что, в свою очередь приводит к "прозрачности" их реализаций (к примеру, представлений)

Минусы :
1. Увеличение числа сущностей БД (таблиц и их метаданных) практически вдвое и, соответственно логики их реализации (грубо говоря, вместо одного представления или ХП надо писать 2).
2. Загруженность сервера "служебной" информацией, в частности лишними индексами. (Это по поводу эффективности индексов)

Жду критики

Anatoly Podgoretsky (2003-02-21 14:09:00) [4]
Не думаю, что бы это увеличило, а вот обратно вполне возможно.

fool (2003-02-21 13:58:00) [5]
Я вооще то согласен, единственное что могу добавить, что вариант 2 можно было бы выбрать при очень больших объемах хранимой информации и(или) при большой загруженности сервера, это несколько увеличило бы скорость срабатывания триггера.

Delirium^.Tremens (2003-02-21 13:15:00) [6]
Вот это ответы! Даже не в глаз, а прямо в корень бьют :-)
Однозначно поддерживаю (хотя им это и не требуется):

Anatoly Podgoretsky © (21.02.03 12:29)
Johnmen © (21.02.03 12:36)

Johnmen (2003-02-21 12:36:00) [7]
Соображения такие:
1. Однотипные сущности хранить в одной таблице.
2. Снижение производительности крайне мало.
3. Время работы триггера опять же ничтожно.
4. Удобство работы с меньшим количеством таблиц.
5. Меньше объектов - меньше процедур обработки - меньше вероятность ошибок

(Из своего опыта - всегда делаю по вар.I)

Anatoly Podgoretsky (2003-02-21 12:29:00) [8]
Смотря какие запросы будут, а сами тригера, редкое и быстрое по времени. Запрос о движении за определенный период по сводной будет проще

MsGuns (2003-02-21 12:24:00) [9]
>Johnmen © (21.02.03 12:21)
>Лично я выбрал бы I вариант из предложенных.

Спасибо, Жень !

Я вообще-то так и сделал :)) Но хотел бы послушать развернутые мнения и ответ на 2-й вопрос (о производительности)

Johnmen (2003-02-21 12:21:00) [10]
Серега ! Тебя тоже поздравляю с праздником !

Лично я выбрал бы I вариант из предложенных.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »