Здравствуйте, chico97, Вы писали:

C>какой вариант сейчас считается правильным в свете наличия таких замечательных обьектов как DataSet и в связи с тем что память все дешевле и дешевле?
C>использовать базу только для "вставить и вынуть" и никаких там хранимых процедур или все в перемежку как и раньше?

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

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

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

Ещё одним "за" в использовании middleware является лучшая сопровождаемость и управляемость программного кода по сравнению с SP. Вспомним хотя бы о необходимости иногда заглядывать в старые версии кода, поиск нужной процедуры среди сотен подобных и т.п.

Но и здесь не всё гладко. Если выносить в middleware пакетную обработку данных, то можно получить обратный результат, который будет работать в десятки раз медленнее, чем если тоже самое сделать на SP. Следовательно всю логику пакетной обработки нужно выносить в SP и запускать это хозяйство по расписанию в часы наименьшей активности.

В общем, компромайз.

Здравствуйте, mogadanez, Вы писали:

M>Здравствуйте, Gollum, Вы писали:

G>>Здравствуйте, mogadanez, Вы писали:

M>>>смысл Датасета не в заполнении его одной таблицей.

G>>Я думаю, ты понял, что я хотел сказать. Вопрос о масштабируемости SP подробно обсуждался например на конференции "Платформа 2003". Можно в датасет тупо пихать 10Гб, но плохая масштабируемость пусть даже и хорошо написанных SP от этого не станет хорошей.

M>Имхо, web — приложение должно быть Stateless. А при каждом обращении клиента заполнять Датасет данными, и теми которые нужны и теми которые не нужны — не самое красивое решение, а решения типа: добавим 8 процессоров и 20 гигов оперативки — согласись единицы проектов могут похвастать таким бюджетом.

А данныезапроса можно кешировать. на бизнес серварах. И тогда меньше обращений к базе. а DataSet и является таким кешем.

Как я понял речь шла о том, что БД всегда узкое место. серверов вокрег одного БД сервера можно поставить несколько, если позволяет архитекутра. В таком случае логику надо по возможности делать в коде, тогда проще добавить еще один сервак вокруг той же базы. Кроме того ХП привязаны к конкретному серверу БД, а если инадо перейти на другой сервер?

M>Вообще, я не использую датасеты, но и логика БД у меня минимальна, сводится к элементарным процедурам.

Здравствуйте, mogadanez, Вы писали:

M>Здравствуйте, Gollum, Вы писали:

G>>железки стоят меньше, если ты не знал.

M>Железяки разные бывают. нам сервак привезли стоит сравнимо с 2000 серваком.
M>если бюджет не позволяет — к вашим услугам хостеры. например Parking.ru — лиценционное ПО имеет.

G>>А спор перестал быть серьезным, не ожидал.
M>так ты юлить начинаешь, это я не говорил, я не это имелл ввиду... получается абстрактный спор.

Железки действительно получаются дешевле. Сколько стоит нормальный сервак? за 5000-20000 баксов можно взять. Это стоимость месяца работы маленькой группы разработчиков. И если тебе для увеличиния количества пользователей надо просто докупить сервак, то это на порядок дешевле, чем переписывать что-либо.

Здравствуйте, Аноним, Вы писали:

А>The main reason why I use sps as BL containers is a possibility to change logik after compilation... No dataset provides you witch such a functionality...

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

А>Что каксается перспектив, имхо, особенно с появлением .NET — будет все большее переползание на ср.слой.
А>Так же (но из разряда "слышел краем уха") вроде в новой версии SQL Server'а с ним вообще можно будет работать средствами .NET (хранимые процедуры на C# )

Ну прямо как SP на Java в Oracle )