alexeyvgПроцедуры - это один из способов разделения уровней приложения.

Т.е. сервер - это не надёжно хранящийся массив байтов, а именно сервер - система, хранящая данные и отвечающая на запросы на получение и изменение данных от других систем.

СУБД отвечает за их целостность, оптимальность операций над ними и т.п. За неё отвечают отдельные специалисты. И интерфейс к СУБД - как раз процедуры. Больше на роль интерфейсов между уравнями ничего и нет.

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

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

В некоторых системах типа САП-а обычные процедуры не используются, но процедуры там всё равно есть, просто для этого сделан свой язык, среда выполнения и все необходимые инструменты.

Разработчик Linq2Sql, конечно, не может правильно оценить такие вещи, тут нужен архитектор, способный взглянуть на всё это шире, не как программист.

хранимые процедуры это конечно хорошо. Вот только что делать, если клиенты написаны с ООП подходом? Вы обьекты прямо на ХП маппить собираетесь?

ViPRosа какие пробемы?
граф обьектов как тянуть собираетесь к примеру? Скажем Streets -> Houses -> Flats. Дома и квартиры будут сразу затянуты на клиента вместе с улицей, или через ленивую загрузку?
Получение обьектов по какому-либо критерию - все дома, где есть владелец квартиры Вася. Тоже будет отдельная ХП, верно?

LSVРасшифруйте, что значит с ООП подходом и чем это противоречит работе через ХП ?
ничем не противоречит. Да вы не стесняйтесь, ответьте для начала на вопрос про графы
LSVВсе современные приложения написаны с ООП.

lol

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

Я говорю именно про граф объектов .


Итак, покажите как вы собрались реализовывать материализацию этих классов из БД использую интерфейс ХП.

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

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

ViPRosесли Именно фильтрация , то можно явно задвать IsNull и т.д.

я надеюсь вы в курсе, что только-что отправили ваш запрос на full scan таблицы?

alexeyvgхранимые процедуры это конечно хорошо. Вот только что делать, если клиенты написаны с ООП подходом? Вы обьекты прямо на ХП маппить собираетесь?Что то я не понял - если в источнике данных нет таблиц, то ООП подход к написанию приложения неприменим? То есть все программы, которые получают данные, например, из Веб-сервисов, файлов, изображений и т.п. не могут быть написаны с использованием ООП?

Это новое слово в теории! :-)

Как раз ООП для варианта с строго прописанными интерфесами взаимодействия систем подходит очень даже хорошо.[/quot]
к вам такой-же вопрос про графы. Расскажите-ка как ваши графы грузяться используя "строго прописанные интерфейсы взаимодействия систем"

alexeyvgКак раз ООП для варианта с строго прописанными интерфесами взаимодействия систем подходит очень даже хорошо

к вам такой-же вопрос про графы. Расскажите-ка как ваши графы грузяться используя "строго прописанные интерфейсы взаимодействия систем"

alexeyvgСоответственно, клиент вызывает процедуру выборки с нужными фильтрами и в параметре указывает, какой вид отображения ему нужен (про этому критерию из этой процедуры вызывается соответствующая процедура отображения найденного результата).

Ну и в крайнем, совсем запущенном случае, можно использовать динамический SQL. Это всё же лучьше, чем формировать SQL на клиенте.

То есть в вашем примере с графом можно сделать 3 процедуры отображения графа с различными атрибутами, и 5 процедур фильтрации, с несколькими наборами параметров. И это покроет все варианты запросов к этим структурам данных.
о как, аж 8 процедур на чтение для 3-х простеньких сущностей. Кроме того, не забывайте, что сущности должны также уметь добавляться, удаляться и апдейтится. Сколько-же их будет?
Можете привести схематично что это за процедуры ? А то честно говоря из того что вы написали я слобо представляю как данные из БД с помощью ваших процедур окажутся в моем графе.
Юзер-кейсы, которые я приводил это поиск 9-ти этажных домов по всем улицам, можно добавить обновление статуса квартиры если задолженность там превысила порог, или удаление чего-нибудь

LSVиз того что вы написали я слабо представляю как данные из БД с помощью ваших процедур окажутся...Это решается повышением квалификации в области СУБД. :)

А теперь поведайте нам про безопасность системы, работающей прямыми запросами.
Также интесна борьба с SQL-injection и присечением выполнения запросов запрещенных логикой приложения.
это вы нам для начала поведайте процедуру перемещения данных их БД в граф объектов, внятного ответа я пока ни от кого не получил.
Или вы за сутки так и не придумали ответ?

alexeyvgА сколько у вас обычно в приложении строк кода, работающих с данными из трёх простеньких сущностей? Я подозреваю, что тыща на сущность, если конечно простенькое приложение. В сложном может быть наверное десяток тыщ.

Вам просто неприятно ТАКОЕ распределение кода между языками? Надо же, 8 (ВОСЕМ!!!) процедур на 3 сущности.

У нас десятки процедур на сущность, ничего страшного. Всё равно клиентского кода получается больше, так что затраты на интерфейс у СУБД маленькие.

Зато он есть, интерфейс.

Насчёт простых добавлений удалений и т.д - в последнем проекте разрабтчики использовали ОРМ для таких операций.

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

Просто вы это программируете не в ХП, а мы в ХП, но кода у нас при этом вряд-ли больше. SQL всё таки достаточно высокоуровневый и выразительный язык.
имхо, вы не так поняли вопрос, который я задавал. Мы сейчас не говорим о распределении бизнес-логики - обсуждается ООП и вся бизнес-логика находиться в объектах, а не в ХП. Мы говорим про то, как читать/добавлять/удалять/обновлять объекты, когда интерфейс БД задан только через хранимые процедуры. Обсуждается только тот кусок системы, который отвечает за маппинг объектов на таблицы базы данных, не больше не меньше.

Повторю начальные условия:
Есть три класса доменной модели -

Есть три таблицы в БД:
Задача - данные из таблиц материализовать в классы модели и обратно.
Один из возможных юзеркейсов - получить коллекцию 9-ти этажных домов со всех улиц. Или проапдейтить статут квартир у которых задолженность выше пороговой.

Для примера, на linq2sql для этого было-бы написано что-то типа:

Был-бы автоматически сгенерирован запрос с джойном между улицами и домами. Резалтсет был-бы затем превращен в классы доменной модели.

Вопрос: покажите, как это будет реализовано у вас, в случае когда таблицы закрыты забором из ХП. Интересует как работает цепочка tables -> ... -> domain class.
Желательно показать кодом (схематично).

ViPRosЕсть навигационный граф, и есть помеченнные подграфы (макротипы).

ну так и покажи на моем простеньком примере как все будет работать вместо вываливания кучи картинок. Задача описана выше.
Какие ХП будут учавствовать, как и кто будет выбирать нужные ХП, как все это превратиться в доменные классы и затем сохраниться обратно. Смелее.
Пока-что из твоих картинок я не вижу ничего нового - загружается подграф целиком вместо только нужных частей. Недостаток этого я указывал выше - на клиента идет масса данных, которые ему не нужна.

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

это сейчас о чем? ;) Про необязательные параметры? При чем тут nullable поля?

допиши эту процедуру, что-бы в случае когда @surname is null поиск происходил только по имени, а когда не null - по имени и фамилии