какой вариант сейчас считается правильным в свете наличия таких замечательных обьектов как 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>согласен. значит работаем по-старому?

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

Здравствуйте, 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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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