Алгоритмика триггера

← →
MsGuns (2003-02-21 12:10) [0]

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

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

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

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

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

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

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

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

← →
Johnmen (2003-02-21 12:21) [1]

Серега ! Тебя тоже поздравляю с праздником !

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

← →
MsGuns (2003-02-21 12:24) [2]

>Johnmen © (21.02.03 12:21)
>Лично я выбрал бы I вариант из предложенных.

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

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

← →
Anatoly Podgoretsky (2003-02-21 12:29) [3]

Смотря какие запросы будут, а сами тригера, редкое и быстрое по времени. Запрос о движении за определенный период по сводной будет проще

← →
Johnmen (2003-02-21 12:36) [4]

Соображения такие:
1. Однотипные сущности хранить в одной таблице.
2. Снижение производительности крайне мало.
3. Время работы триггера опять же ничтожно.
4. Удобство работы с меньшим количеством таблиц.
5. Меньше объектов - меньше процедур обработки - меньше вероятность ошибок

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

← →
Delirium^.Tremens (2003-02-21 13:15) [5]

Вот это ответы! Даже не в глаз, а прямо в корень бьют :-)
Однозначно поддерживаю (хотя им это и не требуется):

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

← →
fool (2003-02-21 13:58) [6]

Я вооще то согласен, единственное что могу добавить, что вариант 2 можно было бы выбрать при очень больших объемах хранимой информации и(или) при большой загруженности сервера, это несколько увеличило бы скорость срабатывания триггера.

← →
Anatoly Podgoretsky (2003-02-21 14:09) [7]

Не думаю, что бы это увеличило, а вот обратно вполне возможно.

← →
MsGuns (2003-02-21 14:50) [8]

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

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

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

Жду критики

← →
Desdechado (2003-02-21 15:35) [9]

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

← →
fool (2003-02-21 15:48) [10]

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

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

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

Алгоритмика триггера Найти похожие ветки