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

C>то есть сейчас всетаки mainstream в отказе от засовывания бизнес логики в хранимые?

Зависит от специфики решения. Я же говорю, когда реально критична масштабируемость, лучше разгрузить БД. Но никто не говорит, что SP теперь вообще не надо использовать. Для тех же датаадаптеров c датасетами вполне можно использовать простые SP для их наполнения. Не нужно лишь всю логику выносить в БД, вот и все.

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...

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

А>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...

Можно заюзать XML, плагины, кучу всего. Но да, это плюс.

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

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

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

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

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

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

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

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

C>>то есть сейчас всетаки mainstream в отказе от засовывания бизнес логики в хранимые?

G>Зависит от специфики решения. Я же говорю, когда реально критична масштабируемость, лучше разгрузить БД. Но никто не говорит, что SP теперь вообще не надо использовать. Для тех же датаадаптеров c датасетами вполне можно использовать простые SP для их наполнения. Не нужно лишь всю логику выносить в БД, вот и все.


почитай внимательно, тут никто и не говорил что ВСЮ логику надо в БД выносить...
все за разумный компромис.

G>Есть веб-гарден с кучей памяти, оптимальным образом настроенный. По сравнению с логикой на SP тупое пихание в датасет будет выигрывать в разы. Железку всегда можно докупить, прогу переписывать зачастую дороже. Если логика на SP железки не спасут.

как это не спасут? Если у тебя есть web-garden, точно так же можно инфраструктуру расширить за счет кластера DB-серверов.
Подход в каждом случае действительно индивидуален, но делать web-garden и зачитывать в DataSet'ы тысячи записей (если идет речь о таких объемах) — такие советы лучше не давать.

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

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

Так кто говорит что надо так делать?? Я только сказал что SP плохо масштабируются вот и все. И подчеркнул, что это актуально только для как раз таких проектов. Да и причем здесть stateful/stateless?

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

Ну и не используй, есть куча альтернатив.

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


M>почитай внимательно, тут никто и не говорил что ВСЮ логику надо в БД выносить...
M>все за разумный компромис.

Нет извини, это ты внимательно почитай. Человек задал вопрос, я проинформировал о том, что знаю, вот и все. Я тоже за компромисс ессно.

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

SFM>как это не спасут? Если у тебя есть web-garden, точно так же можно инфраструктуру расширить за счет кластера DB-серверов.

например, 7-й сиквел не поддерживает кластеризацию вообще. Насчет 2000-го были тоже какие-то заморочки, я сейчас не помню уже.

SFM>Подход в каждом случае действительно индивидуален, но делать web-garden и зачитывать в DataSet'ы тысячи записей (если идет речь о таких объемах) — такие советы лучше не давать.
Никто их и не дает.

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

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

SFM>>как это не спасут? Если у тебя есть web-garden, точно так же можно инфраструктуру расширить за счет кластера DB-серверов.

G>например, 7-й сиквел не поддерживает кластеризацию вообще. Насчет 2000-го были тоже какие-то заморочки, я сейчас не помню уже.

может еще просто ASP юзать а не .NET?

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

M> может еще просто ASP юзать а не .NET?

Если бы ASP.Net стоил столько же, сколько SQL Server 2000, а перед этим я бы купил ASP, я бы крепко задумался.

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

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

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

G>Так кто говорит что надо так делать?? Я только сказал что SP плохо масштабируются вот и все. И подчеркнул, что это актуально только для как раз таких проектов. Да и причем здесть stateful/stateless?

Ты сказал что использовать Датасет быстрее...:

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

P.S. надо заканчивать эту тему... слишком она взрывоопасная

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

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

M>> может еще просто ASP юзать а не .NET?

G>Если бы ASP.Net стоил столько же, сколько SQL Server 2000, а перед этим я бы купил ASP, я бы крепко задумался.

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

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

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

железки стоят меньше, если ты не знал. А спор перестал быть серьезным, не ожидал.

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

M>Ты сказал что использовать Датасет быстрее...:

А ты цитату привел в отрыве от контекста. Если ты не понял что я хотел сказать (в чем я сомневаюсь) то поясню — по сравнению с ХОРОШИМИ SP ХОРОШАЯ реализация логики на датасетах при большой нагрузке на приложение будет быстрее. Переписывать SP ДОРОЖЕ чем докупать железки.

M>P.S. надо заканчивать эту тему... слишком она взрывоопасная

Да я не против.

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

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

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

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

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

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

M>>Ты сказал что использовать Датасет быстрее...:

G>А ты цитату привел в отрыве от контекста. Если ты не понял что я хотел сказать (в чем я сомневаюсь) то поясню — по сравнению с ХОРОШИМИ SP ХОРОШАЯ реализация логики на датасетах при большой нагрузке на приложение будет быстрее. Переписывать SP ДОРОЖЕ чем докупать железки.

я не согласен.

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

C>какой вариант сейчас считается правильным в свете наличия таких замечательных обьектов как DataSet и в связи с тем что память все дешевле и дешевле?
C>использовать базу только для "вставить и вынуть" и никаких там хранимых процедур или все в перемежку как и раньше?
C>просветите пжлста.
Нашёл когда-то где-то (имхо даже по наводке с этого сайта) некую презентацию с логотипом MSDN "Рекомендации в области разработки приложений на .NET Framework" Так там есть такие слова:

Всегда используйте оптимальный Managed Provider
По возможности предпочтитайте использовать DataReader, нежели DataSet
Хранимые процедуры везде, где возможно
Скажите НЕТ динамическим строкам соединения ;]

Вот такие вот дела
За абсолютную истину считать конечно не надо, но прислушаться я думаю стоит.

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

R>Нашёл когда-то где-то (имхо даже по наводке с этого сайта) некую презентацию с логотипом MSDN "Рекомендации в области разработки приложений на .NET Framework" Так там есть такие слова:

R>

R>Всегда используйте оптимальный Managed Provider
R>По возможности предпочтитайте использовать DataReader, нежели DataSet
R>Хранимые процедуры везде, где возможно
R>Скажите НЕТ динамическим строкам соединения ;]

НЕВЕРЮ что такое могло MS сказать . DataReader — только там где ненадо кешировать, в других случаях с DataSet быстрее.

R>Вот такие вот дела
R>За абсолютную истину считать конечно не надо, но прислушаться я думаю стоит.

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

R>Вот такие вот дела
R>За абсолютную истину считать конечно не надо, но прислушаться я думаю стоит.

Не вижу ни слова про бизнес-логику...

А так, подпишусь под каждым словом, обращая внимание на словосочетания "где возможно" и "по возможности"