Каморка

spavel писал(а):

Ага, так и запишем, используется идеологически устаревшая clent-server architecture...

не знаю на счет устаревшая, но про 100 пользователях даст результаты лучше чем новая н-тир... да и работы меньше, и тестить меньше и так далее.

А я там смайлик нарисовал, btw, я согласен, что в каждом случае надо делать то, что больше подходит, а не следовать веяниям моды...

Marmot, не заметил, sorry.

Vovchik писал(а):Фундаментальный изъян в триггерах по большому счету один - теоретическая протеря производительности. Который может быть существенен в практических величинах а может и нет.

А stored procedures производительнее?

Vovchik писал(а):Следующий пункт - это поддержка кода в базе и пр. Но это уже орг проблемы.

Это аудит. К функциональности самого приложения он имеет слабое отношение. Если делать аудит на per-row triggers, то код для них можно копи-пастить с изменением имен полей. Нужен аудит на эту таблицу? Copy-paste, change fild names, create report (which is select from audit table). Просто.

Vovchik писал(а):Естественно ежели кто то ходит через мидл таер то там да один пользователь поскольку с точки зрения базы коннектиться к нему сервер а не юзер. А ежели там коннекшен пул есть как это положено по понятиям то потребовать чтоб кажный юзер ходил в базу со своим именем и паролем - это тебя на части порвут как тряпку.

Порвут ли меня как тряпку если я скажу что куча работников наваливается на сервер в начале рабочего дня и молотит 8 часов с перерывом на обед. Количество работников не может увеличиваться многократно как в Интернет приложении. Это ИнтрАнет приложение. Ну разве что еще босс захочет чего из дома глянуть.

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

Это одна аудит таблица на БД? Круто. Вот только процедура должна постоянно лазить во вспомогательные таблицы.

Я думаю сделать что-то типа такого.
http://www.postgresql.org/docs/8.1/inte ... IT-EXAMPLE

Глядя на этот пример, у меня и возник вопрос о пользователях.

процедура делает все по системным таблицам (например syscolumns - там есть список полей по таблицам) (у нас MS SQL Server)

Когда показываем клиентам в интерфейсе - тогда строим запрос с учетом вспомогательных таблиц.

А как процедура знает какие поля хранить, а какие - нет? Ты же сам сказал что это во вспомогательных таблицах прописано.

spavel писал(а):процедура делает все по системным таблицам (например syscolumns - там есть список полей по таблицам) (у нас MS SQL Server)

Когда показываем клиентам в интерфейсе - тогда строим запрос с учетом вспомогательных таблиц.

Ну это всё хорошо пока нагрузка небольшая...
Тaк что для каждого конкретного случай надо смотреть.
А вот когда будет 1000 updates/sec тогда и захочется вам все эти триггеры прокинуть и начать писать логи проложением прямо в flat file

Очень хочется надеется что 100 работников не натарабанят 1000updates/sec Ну, или по крайней мере, их не надо будет аудитить. А парсить flat file... Нееееееееееееееееееееееееееееет!!!!!!

Marmot, а у нас и того меньше клиентов.. ну может 30-35 одновременно... у них раньше пальцы загнутся.