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

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

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

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

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

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

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

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

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

Аргументы против логики на хранимых процедурах:

1) плохая масштабируемость
2) не очень удобная отладка

Если нужно обеспечить одновременную работу 1000+ юзеров, БД станет бутылочным горлышком.

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

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

А>>а причем тут модно или нет? Все зависит от требований. Если у тебя запрос вернет 10 тысяч записей, потом их фильтровать в среднем слое — не самый оптимальный подход, правда?

C>согласен. значит работаем по-старому?

Работаем по "Правильному"
каждому коду свое место!
безусловно нужен некий баланс, как уже говорили, в зависимости от специфики проекта.

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

G>Хех...
G>Допустим надо достать табличку на 500К

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

G>Что касается огромных объемов данных — если надо прогу затормозить — я ее по любому заторможу. Просто, когда делаешь логику на SP можно и не знать о плохой масштабируемости.

G>З.Ы. Я лично считаю, в каждом конкретном случае оптимален свой подход. Я предпочитаю датасет+датаадаптер с умно сделанными командами, либо датаридер в простых случаях.


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

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

C>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

Позиционирование этих объектов:

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

Датасет — тяжелый объект, однако при интенсивной работе с данными, где используются сложные запросы, и правильном проектировании может дать существенный выигрыш в производительности. Как бы "отсоединенная мини-БД" на сервере. Плюс, связку из датасет + датавью очень удобно использовать для датабайндинга к сложным интерфейсам.

Причем здесь кэширование???

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

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

C>>а зачем мне за справочниками постоянно в базу лазить?

G>Имеется в виду, что нужно либо каждый раз за ними лазить на БД, либо сохранять гденть еще, типа Session. Я думаю, что в большинстве случаев действительно, лучше слазить.

справочники действительно часто выносят, даже за границы ASP.NET процесса(у нас например WinService + Remoting), но они там как правило хранятся не в виде дата сета а в виде "Справочника"

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

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

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

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

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

ИМХО, лучше вставить/вынуть хранимыми процедурами.

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

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

M>ИМХО, лучше вставить/вынуть хранимыми процедурами.
не, ну то что в command text пишем EXEC myStProc... a не SELECT|UPDATE.... это понятно. Непонятно так мы закладываем в хранимые серьезную бизнес логику или нет

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

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

M>ИМХО, лучше вставить/вынуть хранимыми процедурами.
C>не, ну то что в command text пишем EXEC myStProc... a не SELECT|UPDATE.... это понятно. Непонятно так мы закладываем в хранимые серьезную бизнес логику или нет
имхо, в серверном коде

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

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

M>>ИМХО, лучше вставить/вынуть хранимыми процедурами.
C>не, ну то что в command text пишем EXEC myStProc... a не SELECT|UPDATE.... это понятно. Непонятно так мы закладываем в хранимые серьезную бизнес логику или нет

имхо, что иметь в виду под логикой?

например, нужно выбрать нновости начиная с даты Х.

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

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

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

M>имхо, что иметь в виду под логикой?

M>например, нужно выбрать нновости начиная с даты Х.

M>если переносить ВСЮ логику в код, то нужно грузить все новости, и потом в коде их урезать, хотя понятно что каждый будет передавать параметр в ХП и там обрабатывать.

M>пример конечно утированый, но я к тому, что некоторую логику в БД реализовавать просто напросто удобнее...
M>особенно если она касается исключительно представления в БД.
именно так до сего дня я и делаю . все что можно обработать на базе — там и обрабатываю. но мне говорят что теперь так НЕ МОДНО , что мой код сильно часто лазит в базу : нужны новости за сегодня — иду в базу и возвращаю за сегодня, нужны за вчера — опять в базу. А надо говорят взять за неделю — и в коде их фильтровать!
Другой вариант: говорят что вместо сложного JOIN надо все таблицы участвующие в нем выдернуть и уже в DataSet сявязать через Relations — иначе все ОБНОВЛЕНИЯ придется делать через логику прописанную в хранимых, а так мы обновим в DataSet и потом через commandInsert/Update/Delete обновим базу, когда потребуется.
Вот такой расклад.

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

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

извечный вопрос как правило, кто в чем силен.. если в команде есть сильный DB-программер, логика переползает на хр.проц., триггеры, констрейнты. Если программер ср. слоя — то БД как правило — ЧИСТА хранилище данных. Но если не учитывать эти субъективные факторы, все определяется требованиями к системе. Если важна производительность — все же быстрее обраб.данные + закладывать некую логику на SQL Server'е. Если требуется переносимость с одной БД на др. — то всю логику нужно закладывать в ср.слой. Но на практике, как правило, логика — и там, и там.

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

а причем тут модно или нет? Все зависит от требований. Если у тебя запрос вернет 10 тысяч записей, потом их фильтровать в среднем слое — не самый оптимальный подход, правда?

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

А>извечный вопрос как правило, кто в чем силен.. если в команде есть сильный DB-программер, логика переползает на хр.проц., триггеры, констрейнты. Если программер ср. слоя — то БД как правило — ЧИСТА хранилище данных.
имхо такой подход мягко говоря немного странен

А>Но если не учитывать эти субъективные факторы, все определяется требованиями к системе. Если важна производительность — все же быстрее обраб.данные + закладывать некую логику на SQL Server'е. Если требуется переносимость с одной БД на др. — то всю логику нужно закладывать в ср.слой. Но на практике, как правило, логика — и там, и там.
но тогда и отладка и сопровождение станятся труднее

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

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

А>а причем тут модно или нет? Все зависит от требований. Если у тебя запрос вернет 10 тысяч записей, потом их фильтровать в среднем слое — не самый оптимальный подход, правда?

согласен. значит работаем по-старому?

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

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

А>>извечный вопрос как правило, кто в чем силен.. если в команде есть сильный DB-программер, логика переползает на хр.проц., триггеры, констрейнты. Если программер ср. слоя — то БД как правило — ЧИСТА хранилище данных.
C>имхо такой подход мягко говоря немного странен

странный он или нет, но применяется частенько. Это практика, не теория. Мало я видел систем с логикой, полностью прошитой только в БД или только на ср.слое. Бывает, еще и на контроллер интерфейса че-нить переползает Все это не гуд, конечно..

А>>Но если не учитывать эти субъективные факторы, все определяется требованиями к системе. Если важна производительность — все же быстрее обраб.данные + закладывать некую логику на SQL Server'е. Если требуется переносимость с одной БД на др. — то всю логику нужно закладывать в ср.слой. Но на практике, как правило, логика — и там, и там.
C>но тогда и отладка и сопровождение станятся труднее

отчасти

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

я же написал: "краем уха". (т.е. в какой-то статейке с MSDN). Может люди меня поправят.

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

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

А>>а причем тут модно или нет? Все зависит от требований. Если у тебя запрос вернет 10 тысяч записей, потом их фильтровать в среднем слое — не самый оптимальный подход, правда?

C>согласен. значит работаем по-старому?

ну я бы не назвал это "по-старому", стандартный подход в общем-то.

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

.....about Yukon....

Benefit from increased development flexibility. With the common language runtime (CLR) embedded in the database engine, developers will be able to choose from a variety of familiar languages to develop database applications, including Transact-SQL, Microsoft Visual Basic® .NET, Microsoft Visual C#® .NET, and Microsoft Visual J#® .NET. Additionally, CLR integration will provide developers with increased flexibility through the use of user-defined types and functions. The CLR will also provide opportunities to use third-party code for rapid database application development.

http://microsoft.com/sql/evaluation/yukon.asp

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

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

G>Аргументы против логики на хранимых процедурах:

G>1) плохая масштабируемость
G>2) не очень удобная отладка

G>Если нужно обеспечить одновременную работу 1000+ юзеров, БД станет бутылочным горлышком.

Если на 1000+ юзеров, доставать из БД огромные объемы данных, класть их в Датасеты, и ворочать логикой, то ситуация будет не лучше.

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


M>Если на 1000+ юзеров, доставать из БД огромные объемы данных, класть их в Датасеты, и ворочать логикой, то ситуация будет не лучше.

Хех...
Допустим надо достать табличку на 500К

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

Что касается огромных объемов данных — если надо прогу затормозить — я ее по любому заторможу. Просто, когда делаешь логику на SP можно и не знать о плохой масштабируемости.

З.Ы. Я лично считаю, в каждом конкретном случае оптимален свой подход. Я предпочитаю датасет+датаадаптер с умно сделанными командами, либо датаридер в простых случаях.

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

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

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

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

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

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

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

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

Здравствуйте, 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>За абсолютную истину считать конечно не надо, но прислушаться я думаю стоит.

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

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

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

Как автору этой ветки: вот, что пишет Microsoft в Implementing Sun's Java PetStore using Microsoft .Net

The Sun Java Pet Store makes heavy use of Bean Managed Persistence (BMP) in its middle-tier
Enterprise Java Beans (EJB). Essentially, this provides the objects a mechanism to persist their
state to the database. The .NET Pet Shop takes a different approach in that the middle-tier
components make calls to stored procedures in the database. Using stored procedures at the
database level is well established as a best-practice for distributed applications. It provides a
cleaner separation of code from the middle-tier and also helps clarify the transaction context and
scope.Only basic queries are encapsulated in the stored procedures; business logic remains in
the middle tier .NET classes.

Это я к тому, что сами по себе SP это круто, но логику в них держать не надо. Как будет время, нарою материалов для сомневающихся

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

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

вот эта статья...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondevelopinghigh-performanceaspnetapplications.asp

DataSet заполняется адаптером сначала считывая информацию в ридер, и полностью пробегает по нему.

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

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

за ссылку спасибо — прочитаю.

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

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

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

Но это не значит что он не тратит на это время....

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

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

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

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

M>Но это не значит что он не тратит на это время....
да, но дело не в трате времени, а в предназначении.
позиционирование этих обектов очень четкое: кеширить — НЕкеширить

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

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

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

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

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

M>>Но это не значит что он не тратит на это время....
C>да, но дело не в трате времени, а в предназначении.
C>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

что значит кешировать?
Это Веб приложение, тебе при каждом запросе пользователя нужно данные из базы поднимать, зачем их кешировать...
в Win клиенте понятно.

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

M>что значит кешировать?
M>Это Веб приложение, тебе при каждом запросе пользователя нужно данные из базы поднимать, зачем их кешировать...

а зачем мне за справочниками постоянно в базу лазить?
M>в Win клиенте понятно.

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

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

C>>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

G>Позиционирование этих объектов:

G>Датаридер — легкий и быстрый способ считать из базы какую-либо инфу, используется как правило при простых структурах базы и приложения. Предпочтительный способ доступа к БД для большинства простых приложений.

G>Датасет — тяжелый объект, однако при интенсивной работе с данными, где используются сложные запросы, и правильном проектировании может дать существенный выигрыш в производительности. Как бы "отсоединенная мини-БД" на сервере. Плюс, связку из датасет + датавью очень удобно использовать для датабайндинга к сложным интерфейсам.

G>Причем здесь кэширование???

после закрытия соединения как можно в DataReader хранить данные?
для этого отлично подходит DataTable.
именно это я и имел в виду.

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

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

M>>что значит кешировать?
M>>Это Веб приложение, тебе при каждом запросе пользователя нужно данные из базы поднимать, зачем их кешировать...

C>а зачем мне за справочниками постоянно в базу лазить?

если информация грузится один раз, то ИМХО для производительности по барабану как и чем обрабатывать.
тогда уж удобнее грузить справочиники в IDictionary например.

=) ну у тебя же не только справочники в системе... а именно на наиболее загруженной части надо рассматривать проблему.

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

C>а зачем мне за справочниками постоянно в базу лазить?

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

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

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

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

C>>>позиционирование этих обектов очень четкое: кеширить — НЕкеширить

G>>Позиционирование этих объектов:

G>>Датаридер — легкий и быстрый способ считать из базы какую-либо инфу, используется как правило при простых структурах базы и приложения. Предпочтительный способ доступа к БД для большинства простых приложений.

G>>Датасет — тяжелый объект, однако при интенсивной работе с данными, где используются сложные запросы, и правильном проектировании может дать существенный выигрыш в производительности. Как бы "отсоединенная мини-БД" на сервере. Плюс, связку из датасет + датавью очень удобно использовать для датабайндинга к сложным интерфейсам.

G>>Причем здесь кэширование???

C>после закрытия соединения как можно в DataReader хранить данные?
C>для этого отлично подходит DataTable.
C>именно это я и имел в виду.

также для этого чудесно подойдут Собственные entity объекты и их коллекции, с которыми удобно работать.

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

C>после закрытия соединения как можно в DataReader хранить данные?
C>для этого отлично подходит DataTable.

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

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

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

C>>после закрытия соединения как можно в DataReader хранить данные?
C>>для этого отлично подходит DataTable.

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

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

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



C>поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
C>а под кешированием я имею в виду: загрузил однажды — пользушь долго.

Так какая разница как их грузить если это однажды?

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

Долго читал вот эту статью, так и не понял прав я был, или нет... Скорее, видимо, нет, чем да :Р
Буду еще копать эту тему — тем более, что она весьма актуальна.

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

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



C>>поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
C>>а под кешированием я имею в виду: загрузил однажды — пользушь долго.

M>Так какая разница как их грузить если это однажды?
может разницы и нет, но затем их надо где-то хранить и зачем изобретать велосипед если есть такие прекрасные веши как DataTable, DataSet.
Может лучше сосредоточится на бизнес логике?

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

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

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

C>

C>>>поинт в том что справочники я загружаю однажды, а обновляемые данные при запросе странички, потом связываю их.
C>>>а под кешированием я имею в виду: загрузил однажды — пользушь долго.

M>>Так какая разница как их грузить если это однажды?
C>может разницы и нет, но затем их надо где-то хранить и зачем изобретать велосипед если есть такие прекрасные веши как DataTable, DataSet.
C>Может лучше сосредоточится на бизнес логике?

Это и есть логика... справочники ИМХО, удобнее хранить в такой замечательной вещи как HashTable.

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

M>Это и есть логика... справочники ИМХО, удобнее хранить в такой замечательной вещи как HashTable.

При наличии ключа в DataTable поиск будет ни чем не хуже.

Здравствуйте, 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 это позволяет.