pkarklinАбсолютно не согласен. Вы опять посчитали только малую толику затрат. Т.е. Вы не приплюсовали стоимость разработки третьего звена, которое можно было бы и не использовать.
Т.е. вы хотите сказать, что для всех пользователей, имеющих доступ к системе, заведены логины к СУБД и все работает на row level security? Таким образом можно построть только довольно простую систему безопасности с кучей ограничений. А как насчет полноценной role based security с редактируемым списком прав для каждого объекта и наследованием этих прав?возможностью разрешать/запрещать, в общем внешне это очень похоже на права на файлы a-la права в NTFS... Реализуете это средствами СУБД?

tygraЯ еще дальше пойду - напишу вкратце, как оно у нас, а вы уж покажите, в какое место нужно прикрутить ООП_чего-то_там.

Тут трудно сказать в какое место надо ООП прикрутить, скорее надо все выкинуть и написать с использованием ООП, по-другому не получится :)

Дяя создания новой редактируемой таблицы вам придется создать новую форму, написать процедуры для получения информации/изменения/удаления и т.п.
Я могу описать, как это делается у меня.
Есть форма ObjectList, которая отображает объекты любого типа с возможностью сортировки, поиска, постраничного пролистывания и т.п.
В ее конструктор передается параметр типа IObjectType - это те самые метаданные типа, которые кэшируются в сервере приложений.
При изменении, добавлении конкретного объекта на основании этих метаданных автоматически генерится формочка для редактирования/добавления объектов, если есть ссылки на другие объекты, то в зависимости от настроек могут быть разные варианты выбора - или через аткую же форму ObjectList, или через выпадающий список и т.п. На крайний случай можно для какого-нибудь типа переопределить форму выбора элемента.
При удалении объекта автоматически на основании опять же метаданных о связях между объектами вычищаются или не вычищаются всязанные с ним объекты.
В общем, при добавлении нового типа в системе у меня уже есть готовый механизм для редактирования данных объектов этого типа, назначения прав на объекты этого типа и т.п. Писать какой-то код для этого в общем случае не требуется.
Это как раз хороший пример повторного использования кода, который дает ООП в общем и моя реализация в частности.

Насчет прав уточню - если речь идет о том, чтобы просто закрыть доступ ко всем таблицам и открыть только для хранимых процедур, в которые передавать всякие ID пользователя - такой вариант не катит. Это получается то же security на уровне приложения, только это приложение СУБД, а не промежуточного слоя. От моего варианта отличается только тем, что доступ к таблицам у вас закрывается на уровне СУБД, а у меня на уровне сервера приложений, других принципиальных отличий нет, так же как и нет отличий в трудоемкости реализации. Я не говорю про реализацию всего сервера приложений - он вообще-то не для этих целей создавался.

Ну хорошо, определенная часть системы security ложится на плечи СУБД, что ее немного упрощает. Но для меня например неприемлемым является невозможность использования Dynamic SQL в хранимых процедурах. У меня система security не завязана на security СУБД, но по возможностям аналогична.

tygraТут я только не понял - у вас форма на лету создается в процессе выполнения приложения или все же на стадии разработки?
Ну и форма ObjectList - она вроде как одна на всех. А фильтры? Динамически?

Вы про форму редактирования? Да, форма в процессе выполнения приложения создается. Фильтры тоже создаются динамически.

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

Ну так в этом и есть главное отличие - много писать кода или мало, проще поддерживать или сложнее. Все это ведь не ради каких-то метафизических премуществ создавалось или моды, а ради того, чтобы систему проще было расширять и поддерживать.

tygraНо вообще, сейчас к нам вернулся старый товарищ на работу, он разработчик системы ВЕРО - единый реестр объектов. Вот там все автоматизировано на полную катушку - список объектов единый, от него наследуются почти все сущности, есть типы объектов, которые так-же могут наследоваться друг от друга и от них зависит много чего. Система мощная, на объект можно навесить все, что захочется - все это настраивается, так же может быть множество атрибутов (тоже настраивается), независимо от объекта есть универсальные методы, есть собственные, есть мощная система статусов, есть система прав - как общая, так и на конкретный объект - и вся она на базе СУБД.
Но все это делается средствами СУБД, клиент как всегда только отображает и кое-что универсализирует в смысле интерфейса

Ну собственно моя система сильно похожа на то, что вы описали, и довольно много работы в ней также делается в СУБД. Список объектов единый, от него наследуются все сущности, ну и все остальное тоже. Я думаю у Old Nick все по аналогичным принципам построено. Единственно - наследование бизнес-логики делать на уровне СУБД - на эту тему я уже высказывался - это на мой взгляд ненужное извращение.