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

Это необходимое решение для крупной системы. Другого просто нет.

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

Т.е. просто песня какая-то

Бог с ним с гибкостью и скоростью, только этот способ даёт возможность достичь достаточного уровня защиты данных

Цитата

Бог с ним с гибкостью и скоростью, только этот способ даёт возможность достичь достаточного уровня защиты данных

И это тоже. Просто я испытал и гибкость. Вообщем все круто
И однозначно такой подход должен быть использован.

Да - это всеми признанный способ, но не все всегда его придерживаються. Почему? Потому что это занимает гораздо больше времени, чем при топорном подходе.

Я сам предпочитаю использовать только такую архитектуру доступа к БД, и не раз говорил себе спасибо за это. Но в нескольких крупных проектах, наши менеджеры одобрили именно такую (топорную) схему, в связи с тем, что не было достаточно времени на разработку, а результат требовался всего лишь через три месяца. Хотя по всем правилам - на разработку этого софта требовалось около 8-9 месяцев, и то, по приблизительным расчетам.

Спасибо огромное за то что поддержали тему!
1. Гибкость.
Многим менеджерам необходимы отчеты структура которых заранее не определена (типа OLAP). Как это решается хранимыми процедурами?
Количетво процедур многократно превышает количество таблиц. Что делать при изменение логики работы? Менять половину серверной части ради незначительных новшеств? (уже не говоря о переходе на новую версию платформы, где вызовы некоторых системных процедур могут не поддерживаться)
2. Скорость.
На серверной части описывать обработки не очень-то удобно. Иногда приходиться создавать кучу временных таблиц для выполнения простых операций. В подавляющем большенстве случаев безусловно хранимые процедуры быстрее, но иногда из-за ограниченности языка приходиться воротить...
3. Доступ.
Пермишенов достаточно далеко не всегда. Иногда нужно внутри процедуры производить проверку специфических прав пользователей. При изменение этих прав пиходиться производить изменения в тексте процедур, а так как процедур много то задача не простая...

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

Цитата

1. Гибкость. Многим менеджерам необходимы отчеты структура которых заранее не определена (типа OLAP). Как это решается хранимыми процедурами? Количетво процедур многократно превышает количество таблиц. Что делать при изменение логики работы? Менять половину серверной части ради незначительных новшеств? (уже не говоря о переходе на новую версию платформы, где вызовы некоторых системных процедур могут не поддерживаться)

Если говорит об OLAP, то я не встречал менеджеров, которые умели бы по таблицам получать данные - в подавляющем большинстве случаев никто из них не знает структуру таблиц и поэтому все запросы все равно идут к программисту. А программист пишет просто еще одну процедуру.
Если речь идет о смене SQL-сервера, то я на Oracle и MS SQL не испытал огромных перемен при смене версий - практически все функции остались. Если же предполагается использовать SQL-сервера разных фирм, тогда надо думать об организации трех уровней
1. Клиент
2. Бизнас-логика (на Delphi, C++, VB, JAVA)
3. Хранилище данных (только тупые таблицы, никакой логики - SELECT, INSERT, UPDATE, DELETE)

Цитата

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

И курсоры делать приходится, и таблицы временные, язык SQL не для того предназначен - это правда. Но если задача требует больших мощностей, то тогда подключается сервер для отчетов (OLAP), который только отчеты и делает. Причем в этом случае структура данных на нем может несколько отличаться от рабочей структуры для оптимизации запросов. А база делится на оперативную и хранилище.
СтОит также отметить, что сложные случаи бывают не часто, так что можно и потерпеть.

Цитата

3. Доступ. Пермишенов достаточно далеко не всегда. Иногда нужно внутри процедуры производить проверку специфических прав пользователей. При изменение этих прав пиходиться производить изменения в тексте процедур, а так как процедур много то задача не простая...

Но она становится возможной - в случае, если права даются ТОЛЬКО в виде доступа к таблицам это просто иногда не решается никак. Механизм VIEW тоже ограничен в этом вопросе. Да и тогда редактирования тоже не избежать.
Кроме этого я для себя разработал достаточно удобную архитектуру доступа практически к любым объектам базы данных и это требует не очень большого количества переделок. Уверен, что это не единственный существующий способ.
Понятно, что если доступ меняется сразу ко многим объектам, то работы много. Но еще раз повторюсь - подход работы через процедуры дает возможность это сделать проще. А иногда это просто единственный способ при котором можно что-то сделать.

Что-то регистрация отвалилась

По моему личному мнению - бизнес-логика, зашитая в хранимые процедуры, может быть использована только при отсутствии времени на детальную проработку и при полной уверенности, что смены платформы не предвидится. SQL - это не процедурный язык, и решение типа Transact-SQL является лишь компромисом. (Про PL/SQL - не упоминаю, не работал). Наилучшее решение: применение многозвенной архитектуры СУБД <-> Сервер приложений <->Клиент(тонкий). С учетом того, что возможно связывание СУБД и Сервера приложений высокоскоростным доступом или, в крайнем случае (если мощности позволяют), размещение их физически на одном сервере, возражения , что в этом случае снижается производительность, считаю мало обоснованными. Весь вопрос заключается в увеличении сложности разработки подобной системы. Хотя при использовании не самопальных, а промышленных серверов приложений и этот вопрос решается достаточно комфортно.

Цитата

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

Многи финансовые аналитики (особенно молодые) которых я знаю с успехом используют запросы в Access для получения отчетов и имеют неплохое представление о структуре данных. Более того есть замечательные средства типа Decision Cube (Borland Delphi) которые могут избавить программиста от клепания несчетного количества процедур (большая часть из которых становиться не актуальна уже к моменту появления работающей версии) или от необходимости отказывать заказчику.
Vyacheslav, полностью согласен с Вами. С огромным удовольствием обсудил бы проблемы и методики реализации такого подхода в отдельной теме...

Цитата

Кроме этого я для себя разработал достаточно удобную архитектуру доступа практически к любым объектам базы данных и это требует не очень большого количества переделок. Уверен, что это не единственный существующий способ

Если вам не сложно, расскажите подробнее. Я в поисках подобного решения...

Цитата(emchenko @ 17.3.2003, 09:08)

Спасибо огромное за то что поддержали тему! 1. Гибкость. Многим менеджерам необходимы отчеты структура которых заранее не определена (типа OLAP). Как это решается хранимыми процедурами? Количетво процедур многократно превышает количество таблиц. Что делать при изменение логики работы? Менять половину серверной части ради незначительных новшеств? (уже не говоря о переходе на новую версию платформы, где вызовы некоторых системных процедур могут не поддерживаться) 2. Скорость. На серверной части описывать обработки не очень-то удобно. Иногда приходиться создавать кучу временных таблиц для выполнения простых операций. В подавляющем большенстве случаев безусловно хранимые процедуры быстрее, но иногда из-за ограниченности языка приходиться воротить... 3. Доступ. Пермишенов достаточно далеко не всегда. Иногда нужно внутри процедуры производить проверку специфических прав пользователей. При изменение этих прав пиходиться производить изменения в тексте процедур, а так как процедур много то задача не простая... Возможно я глубоко заблуждаюсь, но проблемы мне кажуться очевидными... Есть ли эффективные методики для развития таких проектов?

1) C Репортингом действительно проблемы, хороший репортинг на процедурах не сделаешь, для серьёзной работы надо делать репорт-сервер, или что-то ещё

2) Ну так и делайте временные таблицы, просто доступ из вне остаётся через SP...

3) Да, не всё так просто, но хочу заметить что работа через SP еднственно возможный способ сделать нормальное разграничение доступа пользователям к базе данных, другого просто нет!

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

Проблема доработок всё равно остаётся - как ни делай, а практика показывает, что всё равно прийдётся менять и клиента, и сервер и добавлять поля, таблицы, view, sp - как бы продуманна система ни была, и чем больше система, тем большее количество "слоёв" прийдётся менять даже при небольших доделках...

Цитата

3) Да, не всё так просто, но хочу заметить что работа через SP еднственно возможный способ сделать нормальное разграничение доступа пользователям к базе данных, другого просто нет!

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

Цитата

Проблема доработок всё равно остаётся - как ни делай, а практика показывает, что всё равно прийдётся менять и клиента, и сервер и добавлять поля, таблицы, view, sp - как бы продуманна система ни была, и чем больше система, тем большее количество "слоёв" прийдётся менять даже при небольших доделках...

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

Цитата

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

Насколько я понимаю вопрос, обсуждается именно архитектура клиент-SQLсервер.
И вот для такого случая SP для разграничения полномочий вещь особо ценная.

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