Все новости от 27 октября 2005 г.

ОРП (ORM): зачем это нужно?

Объектная и реляционная ортогональны. Это значит, что они моделируют одну и ту же сущность, но с разных сторон, под разными, я бы сказал перпендикулярными, углами зрения. Реляционная модель акцентирует свое внимание на структуре и связях сущностей, объектная - на их свойствах и поведении. Цель использования реляционной модели - информационное моделирование, выделение существенных для нас атрибутов, сохранение их значений и последующего поиска, обработки и анализа. Цель использования объектной - моделирование поведения, выделение существенных для нас функций и последующего их использования. Между моделями есть пересечение - структурные сущности, которые по-разному в этих моделях отражаются. Для того, чтобы отобразить артефакты реляционной модели в артефакты же объектной, в наших программах и требуется средство объектно-реляционной проекции - ОРП или широко распространенное англоязычное обозначение - ORM (Object Relational Mapping).

Выражаясь более простым языком, объектно-реляционный проектор - ОРП - позволяет программисту прозрачно работать с таблицами, полями и связями реляционной БД, как с объектами, свойствами и коллекциями (массивами), не отвлекаясь на подробности более низкого уровня, такими, например, как порядок выборки и сохранения модифицированных данных, вопросы переносимости и особенностей диалекта SQL конкретной СУБД, генерации уникальных первичных ключей, заполнения полей ссылок для моделирования связей.

Рассмотрим для сравнения код с использованием ADO.NET и ОРП.

ADO.NET

SqlConnection myConnection = new SqlConnection(myConnectionString);
// Создаем два объекта DataAdapater для таблиц Customers и Orders
SqlDataAdapter mySqlDataAdapter = new SqlDataAdapter("select * from customers", myConnection);
SqlDataAdapter mySqlDataAdapter1 = new SqlDataAdapter("select * from orders", myConnection);
DataSet myDataSet = new DataSet();
object DataRow myDataRow;
// Создаем объект command builder для работы с таблицами Customers и Orders
SqlCommandBuilder mySqlCommandBuilder = new SqlCommandBuilder(mySqlDataAdapter);
SqlCommandBuilder mySqlCommandBuilder2 = new SqlCommandBuilder(mySqlDataAdapter1);
// Заполняем DataSet-ы
mySqlDataAdapter.Fill(myDataSet,"Customers");
mySqlDataAdapterl.Fill(myDataSet,"Orders");
// Добавляем связь между таблицами
myDataSet.Relations.Add("CustOrders", myDataSet.Tables["Customers"].Columns["CustomerId"], myDataSet.Tables["Orders"].Columns["CustomerId"]);
// Меняем значения поля ContactName первой строки Customer
myDataSet.Tables["Customers"].Rows[0] ["ContactName"] ="Peach";
// Добавляем строку в Customer и инициализируем поля
myDataRow = myDataSet.Tables["Customers"].NewRow();
myDataRow["CustomerId"] ="TST4";
myDataRow["ContactName"] = "New Contact Name";
myDataRow["CompanyName"] = "New Company Name";
myDataSet.Tables["Customers"].Rows.Add(myDataRow);
// Добавляем новый Заказ для данного Клиента
DataRow orderRow = myDataSet.Tables["Orders"].NewRow();
orderRow["OrderDate"] = DateTime.Now;
// Устанавливаем связь "родитель-потомок"
orderRow.SetParentRow( myDataRow, myDataSet.Relations["CustOrders"]);
// Добавляем строку в DataSet
myDataSet.Tables["Orders"] .Rows.Add(orderRow);
// Вносим изменения в базу данных
mySqlDataAdapter.Update(myDataSet, "Customers");
mySqlDataAdapterl.Update(myDataSet, "Orders");

ОРП

// Создаем новый объект DataManager и соединяемся с базой данных
// Объект Config берет данные из стандартного файла конфигурации App.config
DataManager data = new DataManager(Config.Dsn);
// Создаем коллекцию объектов Клиент(Customers) и связанных с ними Заказов и заполняем ее данными из базы данных
CustomersCollection customers = data.GetCustomersCollection (FetchPath.Customers.Orders);
// Изменяем атрибут ContactName для Клиента с CustomerId = "ALFK1"
customers.FindByCustomerID("ALFK1").ContactName = "Peach";
// Создаем нового Клиента
// В объектной модели атрибуты CustomerId и CompanyName описаны, как обязательные для заполнения
Customers customer = data.NewCustomers( "Tst7", "Olero Software, Inc.");
customer.ContactName = "Tech Support";
// Создаем новый Заказ для Клиента
Orders order = customer.NewOrders();
order.Customer = customer;
order.OrderDate = DateTime.Now;
// Вносим изменения в базу данных
data.CommitAll();

Преимущества подобного подхода очевидны:

• рутинный код манипуляции данными в программах уменьшается в среднем на треть по сравнению с работой через классические табличные DataSet;
• в архитектуре приложения можно четко разделить слой хранения данных, обеспечиваемый СУБД, и слой прикладных объектов (или "бизнес-объектов", business objects layer).

Разумеется, за все нужно платить. ОРП является дополнительным слоем абстракций и создает накладные расходы по использованию процессора и памяти, а работа с реляционной СУБД становится в некоторых случаях неоптимальной или даже неудобной по сравнению с SQL-командами. Не следует также забывать, что SQL - это промышленный стандарт, тогда как внутренние языки запросов, используемые в ОРП, таковым не являются. Поэтому кроме объектно-ориентированной работы с данными большинство ОРП поддерживают возможность прямого использования SQL и вызовов хранимых процедур, а некоторые могут даже отображать объекты на хранимые процедуры. Данные возможности следует отнести к разряду оптимизации, сейчас мы не будем их рассматривать подробно, но если ваша БД содержит миллионы записей при одновременном доступе множества пользователей, то с большой вероятностью вам они понадобятся.

Из уже названных различий между целями использования реляционной и объектной моделей следует, в частности, что если в вашей системе основной упор делается на многокритериальный поиск и массированное извлечение информации (класс информационно-поисковых систем, OLAP, генерация отчетности), то использование объектов для доступа к данным не является оправданным, а попросту излишне. Никакого различия между табличным представлением информации в базе данных, внутри вашей программы и на экране пользователя или в отчете нет, промежуточная обработка сводится к соединениям все тех же таблиц и простым пересчетам значений их полей. Другое дело, если ваша система осуществляет транзакционную обработку (OLTP), сложные расчеты, оповещения о событиях, диспетчеризацию, моделирует поведение - здесь преимущества использования ОРП наибольшие.

Более подробно о портрете "идеального" ОРП, обзоре имеющихся на рынке продуктов и основных выводах вы можете прочесть в полном варианте статьи на сайте автора: Обзор средств объектно-реляционной проекции (ORM) для платформы .NET

Об авторе:
Сергей Тарасов работает архитектором информационных систем.

Обсуждение и комментарии

	RaDiy - radiypochta.ru 28 Oct 2005 2:43 AM
Зачем нужно писать такие стать?? Что бы что?? Что бы увидеть на зд нете свою фамилию?? Что бы покрасоваться перед коллегами - "Вот я какой умны!!"?? Никакой пользы от данной статьи нет.... есть просто пустое сотрясание воздуха....
	unknown 28 Oct 2005 5:04 AM
Н-даа как все запущено ... Говоря языком автора идеи высказанные в статье ортогональны здравому смыслу и параллельны бреду :) Хмм по моему даже студент первокурсник сможет написать SQL запрос лучше чем данный "архитектор информационных систем". Ну например "SELECT sum(AccountAmount) FROM Customer C join Accounts A on C.AccountID = A.OID WHERE Country = 'Россия'" Здесь сервер БД все услужливо сам сложит и вернет требуемую сумму в одной ячейке БЕЗ необходимости пересылки ВСЕХ данных и написание программы для сложения. Гораздо эффективнее чем "ОРП" подход предложенный автором. Может быть иммено поэтому реляционные БД так популярны? Вообщем автору совет: купить какую-нибудь толстую книжку по SQL и грызть гранит науки или сменить род занятий как я слышал у нас в стране катастрофически не хватает ассенизаторов...
	Коляныч - kolanychmail.ru 28 Oct 2005 2:40 PM
кг/ам: для подобных примеров более подходит datareader, а не dataset, о чем написано в любой книжке про .нет ... вкупе с указанным уже незнанием сиквела предыдущий совет вполне уместен
	Dzianis Koshkin - k5yandex.ru 29 Oct 2005 8:26 AM
Гибридное использование подходов OOP и RDB имеет концептуальную непродуманность. Всякие оптимизирующие решения для их совместного использования (DataSet, Java Beans, ADO.NET, всевозможные mapper'ы, проекторы, UML ER преобразователи модели данных на плоские, примитивные таблицы RDB) будут временными, не лучшими решениям, несущие глубинные недостатки для дальнейшего развития информационных систем.
	Коляныч - kolanychmail.ru 29 Oct 2005 11:30 AM
2Dzianis Koshkin : ms щас пытается реализовать преимущества субд при обработке данных в ооп, см. проект http://msdn.microsoft.com/netframework/future/linq/ ... посмотрим, что получится что касается нашего "архитектора" и уважаемой редакции: править текст статьи после опубликования и отзывов на описанный там бред есть не что иное, как попытка выставить всех отрицательно отозвавшихся идиотами! ну да ладно, в новой интертрепации (!) понимания "архитектором" концепции сиквела и .нет стало совсем понятно, откуда ноги растут ... да-да, уважаемые, не удивляйтесь сильно, но ОРП - это 1С 8.0, настолько похожи они в подходах. учитывая, что 1С уже расписалась в своей большой ошибке с 8.0, взяв за основу будущей версии vs for app, то кто-то тут жутко стормозил, догадайтесь с одного раза:)) что касается приведенного кода - по прежнему полная безграмотность налицо, уже даже описывать скучно (например использование прямых запросов, а не хранимых процедур сократит первый текст до нескольких строк, а про выборку полной таблицы на клиента и ее обработку я вообще молчу, про C/S "архитектор" пока не знает)
	Павел 29 Oct 2005 2:22 PM
2 RaDiy Абсолютно согласен. Сразу захотелось сказать "автору" КГ/АМ. 2 Dzianis Koshkin >Гибридное использование подходов OOP и RDB имеет концептуальную непродуманность То есть использовать БД из ОО языков не стоит? И собсно как после этого жить ;). 2 unknown >Здесь сервер БД все услужливо сам сложит и вернет требуемую сумму в одной ячейке Можно использовать агрегацию и с ORM. С ORM можно даже SQL чистый использовать, а ORM использовать только для того, чтобы ходить не по абстрактным строкам, а по объектам.
	Сергей Тарасов - sergearbinada.com 29 Oct 2005 2:45 PM
Dzianis Koshkin, я отчасти согласен, объектные СУБД решают проблему красивее, пишется минимум кода. Для OLTP. Но для аналитической обработки и многокритериального поиска их эффективность более чем сомнительна. Главное преимущество использования ООБД - в определении интерфейсов и реализации методов средствами самой ООБД. Но инкапсуляция делает невозможным построение оптимального плана запроса. Фильтрация по значениям, возвращаемым такими методами не может быть эффективно оптимизирована, более того, при вызове метода не гарантируется неизменность состояния объекта. Аналогичная проблема стоит и для РСУБД - использование функций и хранимых процедур в запросе требует ручной оптимизации ad hoc, а то и просто невозможна. Но в РСУБД функции не являются артефактами реляционной модели, в отличие от объектной. Если интересно, вот ссылка на давнее обсуждение в fido7.su.oop http://groups.google.com/group/fido7.su.dbms/browse_frm/thr ead/afe2923d676e1158/feb1515f8427ec25?tvc=1&hl=ru Таким образом, при использовании ООБД необходимость в "гибриде", но теперь уже и на уровне данных, а не только на уровне приложения сохраняется - надо иметь "рядом" РСУБД для поисковых и аналитических задач. Следует помнить, что гибрид на уровне приложения может быть как клиентским (относительно СУБД) процессом (рассматриваемые в статье ОРП), так и серверной in-process надстройкой над СУБД средствами хранимых процедур и view. Наш многолетний опыт в этой области позволяет утверждать об эффективности такого подхода, хотя недостатки - жесткая привязка к СУБД, не вполне адекватный задачам процедурный язык программирования, ограничения масштабирования - также очевидны. На эту тему есть статья "Реализация сервера объектного представления средствами реляционной СУБД на примере MS SQL Server 2000 и CASE ERwin" http://www.arbinada.com/modules.php?name=Content&pa=showpag e&pid=68 и работающая SmallERP система http://nexus.arbinada.com/
	Сергей Тарасов - sergearbinada.com 29 Oct 2005 3:02 PM
И еще по поводу ООБД, цитата из обсуждения с пользователями GemStone. ---- Пишем ли мы на SQL SELECT * FROM SomeTable WHERE condition или на Smalltalk SomeCollection select: condition разница не так уж велика. Пусть есть отношение 1:N, скажем, АвиаБилет и КупонАвиаБилета, авиабилеты "содержатся" в коллекции КоллекцияАвиаБилетов (глобальная или класс-переменная), а купоны "содержатся" каждый в своем билете (билет хранит ссылку на коллекцию купонов, купон хранит ссылку на свой билет). Мне надо посчитать кое-что по билетам и купонам . Скажешь, джойнов нет? Да, формально нет. Hу и что? При определенных условиях мне выгодно пройтись по коллекции билетов, спрашивая у них купонах, при других условиях - пройтись по общей коллекции купонов, спрашивая у них билеты. "Условия" - это не только search conditions, но и, скажем, cardinality, clustering и т.п. Hеплохо бы таки иметь возможность переложить принятие такого решения на оптимизатор? Увы, в GemStone такого нет.
	smith - ask-meask-me.ru 29 Oct 2005 9:52 PM
Автор очевидно не знал что давным давно проблема решена. Решение называется Cache. Полнейший бред а не статья!
	unknown 29 Oct 2005 10:32 PM
Че-то не понял, а где пример со сложением счетов? Хммм видимо это новая версия. Кому интересно прежний опус господина Тарасова еще лежит в гуглевском кэше http://64.233.183.104/search?q=cache:O1GUa7b54N0J:www.zdnet. ru/%3FID%3D501129 Ну и что мы видим новенького? Еще один кривой пример? Видимо наш архитектор явно не дочитал до главы где рассказывается про SQL команды INSERT и UPDATE. Вообще же говоря приведенные примеры просто поражают своей безграмотностью. Как уже писал Коляныч наш архитектор похоже не понимает что такое DataSет. Вкратце это полная копия таблицы из БД которая передается клиенту. Я конечно понимаю что у Тарасова SQL сервер стоит локальный и в таблицах не более чем 10 записей. Так что все работает быстро. Однако если в таблице записей несколько миллионов и сервер удаленный соединен через 10 мбит канал да несколько клиентов то все эти "select * from orders" просто вырубят систему к черту. Так что DataReader единственная реальная альтернатива. Здесь вот есть небольшая статья по теме http://davidhayden.com/blog/dave/archive/2004/09/13/473.aspx Кстати даже с заголовком Тарасов напутал вон Википедия утверждает что корректное название технологии пропагандируемой архитектором является Object-SQL mapping http://en.wikipedia.org/wiki/Object-relational_mapping Короче Сергей прекратите насиловать C# и займитесь чем нибудь более полезным - езжайте вон в Бобруйск саранчу разводить.
	00alex 29 Oct 2005 11:02 PM
Народ, я весь пол-инета облазил, поясните, что такое КГ/АМ... В Бобруйск не посылать ;-)
	unknown 29 Oct 2005 11:12 PM
00alex Креатифф Гавно/Аффтар Мудак
	Сергей Тарасов - sergearbinada.com 29 Oct 2005 11:56 PM
unknown>архитектор похоже не понимает что такое DataSет. Вкратце это полная копия таблицы из БД которая передается клиенту А вот, скажем, если не select from как в примере на базе pubs с десятками записей, а еще where в запросе присутствует, то это как, уже не DataSet называется? :)
	unknown 30 Oct 2005 1:00 AM
2Сергей Тарасов Прекратите позорится. Результатом работы любого SELECT'а с WHERE или без него будет набор данных в ТАБЛИЧНОМ формате (за исключением SELECT'ов которые ничего не возвращают). При использовании .NET класса DataSet таблица соответствующая результатам SELECT'a будет ЦЕЛИКОМ скопирована клиенту (гигабайт значит будет передан гигабайт) плюс .NET еще удвоит ее (оригинальная и с изменениями). DataReader же копирует только те строки которые к которым программа пытается получить доступ. В любом случае в приведенном пример SELECT вообще не нужен. Достаточно использования INSERT и UPDATE (данные только передаются на сервер)
	unknown 30 Oct 2005 2:15 AM
ААА Я кажется понял что смущает Тарасова. Видать он даже главу про SELECT до конца не осилил. А то я уж начал метать бисер ... Видимо он думает что таблица это только то что у него в Enterprise manager подписано Table. Про то что SELECT записывает свои результаты в отдельную временную таблицу он даже и не подозревает и скажем "select a from (select 1+1 as a) x" с точки Тарасова работать ну ни как должно (в поле from другой select). Ну а может это оно и правильней, зачем спрашивается архитекторам информационных систем замусоривать свои светлые головы каким-то глупым SQL?
	Сергей Тарасов - sergearbinada.com 30 Oct 2005 2:33 AM
unknown, я ведь вопрос задал, а вы не ответили, нехорошо :) Так как, select where - это DataSet или уже нет?
	M&M's 30 Oct 2005 11:57 AM
2 unknown: аднака не поверю, что при SELECT WHERE клиенту будет передана ВСЯ таблица, невзирая на условия выборки. Они же не настолько мудаки, в самом деле. А датасет - он и с полной таблицей датасет, и с выборкой датасет, какая разница?
	torvic 30 Oct 2005 2:10 PM
2 Сергей Тарасов Устроить какое-либо осмысленное обсуждение на зднете ещё никому не удавалось; мне кажется более продуктивно дать ссылку для заинтересованных людей на аналогичное обсуждение на КД.
	Прохожий 30 Oct 2005 3:26 PM
Для M&M's и Сергея Тарасова Клиенту не будет отдана вся таблица при наличии WHERE в операторе SELECT. Но предположим, что исходная таблица состоит из 10 миллионов строк, а WHERE ограничивает её до всего лишь 1 миллиона. Вам от этого легче станет?
	M&M's 30 Oct 2005 7:05 PM
2 Прохожий Мне уже стало легче, спасибо.
	unknown 30 Oct 2005 9:10 PM
2Сергей Тарасов и M&M's DataSet, DataSet. Вы не просто не понимаете о КАКОЙ таблице идет речь. SELECT по завершении своей работы создает новую ВРЕМЕННУЮ таблицу которая содержит результы его работы. Например если вы из таблицы содержащей 5 миллионов записей выбрали (ну например с помощью WHERE) 1 миллион будет создана НОВАЯ ВРЕМЕННАЯ таблица содержащая этот 1 миллион. Далее читать внимательно: при использовании .Net класса DataSet таблица содержащая 1 миллион записей будет скопирована в двух экземплярах клиенту. А при использовании DataReader это таблица (1 миллион) останется на сервере БД и строки будут передаваться по мере надобности. Таким образом результат SELECT'a (c where, с group by, с джойнами или без оных) мозжно заполучить как в виде .NЕТ DataSet так и в виде .NET DataReader. Поэтому ваш вопрос не имеет смысла, просто показывает ваше полное незнание предметной области.
	Не Лох 30 Oct 2005 10:38 PM
Послушайте уважаемый unknown В статье четко и ясно написано, что для вывода отчетов всяких на экран ОРП использовать не стоит. Речь идет об ОЛТП, т.е. ввод единичной информации. Например заказ. Такая информация характеризуется большим количеством взяимосвязанных обьектов (Заголовок заказа, строчки заказа), которую надо внести и сохранить вместе. Вот тут то ОРП и поможет, поскольку во первых позаботится о транзакционности. Во вторых о проверках данных, в третьих избавит от множества update запросов. В этом случае не требуется никаких выборок из базы, поскольку все обьекты выбираются по ключам. Т.е select с where OrderID = 1234 всегда будет возвращать очень маленьких набор записей. Опять же считать суммы посылая sum(amount) на сервер когда у вас в программе все строчки заказа уже загружены, будет делать только идиот. Не путайте область приложения инстурмента, и не будет вам казаться что кто то пытается заменить sql. Каждый инстурмент хорош на своем месте.
	Максим 30 Oct 2005 11:28 PM
2Не Лох: А завтра "архитектор" добавит OrderComponentID, т.к. в одном заказе может быть N элементов, и система вдруг станет резко задумчивей... да?
	unknown 31 Oct 2005 12:53 AM
2Не Лох >Опять же считать суммы посылая sum(amount) на сервер когда у вас в программе все >строчки заказа уже загружены, будет делать только идиот. Никто и не оспаривает что когда все строчки заказа уже загружены то лучше суммировать на стороне клиента. Проблема только в том что если этих строчек несколько миллионов и сервер удаленный то загружаться они будут ой как неспешно. Так что в реальных приложениях (с большими обьемами данных) практически ВСЕГДА лучше выполнять такие вычисления на стороне сервера с помошью агрегатных функций. Насчет ввода единичной информации. Ну возможно то что вы говорите про ОРП и имеет смысл (транзакционность,контроль типов и updatе'ы сами генерятся). Только что мы видим у Тарасова? Сначала он рассуждает про ортогональность обьектной и реляционный моделей (sic!). Затем в качестве проблемы упоминает генерацию уникальных первичных ключей (бред сумасшедшего). Ну и самое главное в Ado.Net примере он для того чтобы изменить пару полей сначала качает 2 полных таблицы (нафига?) и затем на стороне клиента их насилует. Почему он не пользует Update'ы и Insert'ы, не знает как? Плюс ко всему статья написана каким то псевдонаучным языком и снабжена примерами из серии "мой первых опыт на C# (как не надо писать программы)"
	Сергей Тарасов - sergearbinada.com 31 Oct 2005 12:41 PM
torvic, Я вообще не планировал обсуждать тут, тем более статья скорее манагерско-архитектурного плана, да и привиден только начальный кусок из нее. Ссылка на КД http://www.delphikingdom.com/asp/talktopic.asp?ID=337 P.S. Я сам был долгое время противником ОРП-подхода, сказывался долгий опыт разработки логики средствами СУБД, пока не осознал, что это просто удобный в ряде случаев заменитель работы с DataSet.
	Сергей Тарасов - sergearbinada.com 31 Oct 2005 1:07 PM
unknown, не поленитесь посмотреть, какой полный набор для генерации идентификаторов предлагает NHibernate. Описал один раз в модели - в коде больше не нужно ничего делать. Переехал на другую СУБД - просто поменял описание, старый код работает. Хотя, наверное, зря я это все Вам говорю. http://nhibernate.sourceforge.net/nh-docs/html/mapping.html #mapping-declaration_id
	kand 31 Oct 2005 4:49 PM
2 Сергей Тарасов: Не стоит метать бисер перед свиньями. Лучше беседовать с вменямыми людьми, в каком-нибудь другом месте.
	Не Лох 31 Oct 2005 7:18 PM
2 unknown >>> Проблема только в том что если этих строчек несколько миллионов и сервер удаленный то загружаться они будут ой как неспешно. Какие это миллионы строчек в одном заказе ? :))) Вы уважаемый опять путаете сферы приложения. Сказано же вам - ввод и редактирование единичной информации. Для отчетов с миллионами строчек никто вам ОРП использовать не предлагает. SQL никто не отменял. 2 Максим >>>А завтра "архитектор" добавит OrderComponentID, т.к. в одном заказе может быть N элементов, и система вдруг станет резко задумчивей... да? Не знаю как там в NHibernate, я работаю только с java. Но в java Hibernate есть опция lazy-loading. Т.е. связанные списки обьектов (parent-child) могут загружаться не сразу а при первом обращении. Так что ничего тормозить не будет. Это во первых. Во вторых при работе с один обьектом, пусть и сложным со смногоми компонентами, речь идет о порядке в десятки, максимум сотни записей. Но уж никак не тысячи или миллионы. В третьих во многих ОРП инструментах есть встроенные средства кеширования, которые вообще убирают повторные запросы в БД. Так что все эти проблемы давно и успешно решены.
	eXOR 1 Nov 2005 12:14 AM
Да уж. Песнь про тех самых, незабываемых пионеров. Придумывающих себе проблемы и с успехом их преодолевающих. Ну и после всего, следующих по направлению, указанному еще Ф.Раневской.
	unknown 1 Nov 2005 1:00 AM
2Не Лох >Какие это миллионы строчек в одном заказе ? :))) Мой комментарий про sum(amount)и миллионы строк относился к безвременно канувшему в лету первоначальному примеру г-на Тарасова (позднее в статье он был изменен на текущий пример с обновлением строк, видимо под влиянием критики) 2Сергей Тарасов Ну посмотрел я вашу ссылку. Первоначальное впечатление что это еще одна "серебряная пуля". Т.е. зависимость от диалекта SQL (а большая ли она?) предлагется променять на зависимость от ОРП библиотеки (будем ждать когда появятся библиотеки спасающие от ОРП зависимисти?). Потом почему вы думаете что код перестанет работать после смены СУБД (а вообще часто ли тип СУБД меняется)? Если делать все по умному, SQL хранить в хранимых процедурах то какие проблемы? Немного подправить SQL, заменить драйвер и все. Кроме того здесь вам были заданы ряд весьма конкретных вопросов по статье которые вы почему то упорно игнорируете. 2kand Да уж куда нам сирым да убогим до недосягаемых высот Тарасова. Спасибо барину и на том что пишет статьи заумные - нас идиотов просвещает. Сидели бы мы наверное без таких вот архитекторов при свете свеч и радовались бы ржавому радио :) 2eXOR зачот :)
	Не Лох 1 Nov 2005 4:12 AM
2 unknown Зависимость от sql сама по себе не есть ни плохо ни хорошо. Если не мешает зависимость от sql - то не думаешь об этом. Если мешает, стараешься найти решение. ОРП - это и есть такое решение, для тех кому привязка к конкретному серверу БД - проблема. Например к поставщикам коробочных продуктов. Ну не придешь блин к клиенту и не скажешь. Моя супер-пупер програ работает только на MS-SQL? так что давай барин, покупац MS-SQL? даже если у тебя Оракл стоит. Тут надо уметь ставить продукт на ту базу которая у заказчика уже стоит. Ну а если ты для внутреннего пользования пишешь, то привязка к sql не имеет никакого значения. >>>Если делать все по умному, SQL хранить в хранимых процедурах то какие проблемы? Проблемы с привязкой к конкретной БД, смотри выше. 2 eXOR Да у тебя на MS-ACCESS с тремя табличками уж точно никаких проблем. Простой блин как утюг :))
	злой 1 Nov 2005 11:09 AM
использование ORM средств, с ООП языками программирования очень удобно, ведь куда лучше, иметь дело с коллекцией объектов, замапленых на таблицу, чем с каким то там DataSet'ом, который по сути представляет двумерный массив. И изметять/получать данные, удобнее через привычные для ООП программиста (java/c#) объекты и их методы getXXX()/setXXX(), а не через SQL. Лично я пользую Hibernate в связке с JSF и это просто сказка :) Сейчас потихоньку переползаю на EJB3, скоро выйдет окончательная спецификация, которая окончательно раставит все точки над ORM средствами для Java. Ну а ребятам из детского сада (unknown, eXOR) советую закончить школу, хотя бы, а потом уже лезть сюда со своими примитивными мыслишками.
	злой 1 Nov 2005 11:16 AM
Кстати, ORM средства среди Java программистов - обычное дело, они уже применяются очень много лет и прошли очень долгий путь эволюции, а вот для C# программистов, это что то новое и как следствие принимается по началу в штыкы, тут сказывается общая отсталость .net, который с момента создания все время где то там, в жопе плетется, ну нечего, вижу что и в .net уже ORM потихоньку внедряется.
	torvic 1 Nov 2005 12:09 PM
> который с момента создания все время где то там, в жопе плетется generics, application domains, boxing/unboxing, attributes, ... Теперь ещё и LINQ, сдаётся мне сейчас это спорный вопрос.
	xacid 1 Nov 2005 9:02 PM
>Я сам был долгое время противником ОРП-подхода, сказывался долгий опыт разработки логики средствами СУБД, пока не осознал, что это просто удобный в ряде случаев заменитель работы с DataSet. не только особенную пользу приносит это вместе с адекватным моделированием предметной области средствами ООП
	nash 3 Nov 2005 7:29 PM
Да, конечно, докопался _неизвестный_ до автора не по делу. Ну пример ведь на то и пример, только идею показать. Какие десять/миллион записей? При чем тут это? Сам, наверное, знакомые буквы увидел? Так хамить по поводу книжек про селект ИМХО не достойно. Идея, конечно, не новая, но где здесь написано что это новье? И про Каше (из обсуждения) и про остальное все давно известно. Просто вот такая статья. Может кому интересна, кому нет. Другое дело, что автор я смотрю пиариться во всю. И не он ли рассылку спамовую устраивал продвигая свою ерп-систему ???
	ASD 4 Nov 2005 11:49 AM
2Author ...не отвлекаясь на... ...вопросы переносимости и особенностей диалекта SQL конкретной СУБД, Вы таки архитектор? Удивительно. Не отвлекаюсь на вопросы переносимости и особенностей диалекта SQL конкретной СУБД - лучший способ написать медленноработающее приложение. Неужели это не очевидно ?
	xacid 4 Nov 2005 8:06 PM
приложение иногда лучше медленно но правильно работающее, чем наоборот
	злой 5 Nov 2005 6:21 PM
2ASD Вы таки архитектор? Удивительно. Не отвлекаюсь на вопросы переносимости и особенностей диалекта SQL конкретной СУБД - лучший способ написать медленноработающее приложение. Неужели это не очевидно ? == Очевидно, только так же очевидно то, что сейчас на первом месте при разработк ПО стоит скорость самой разработки, а не скорость работы ПО. И такие фреймвори как ORM этому способствуют.
	Сергей Тарасов (но не автор статьи) 5 Nov 2005 10:30 PM
Суть вопроса в том, что рассматривается следующий уровень абстракции, стоящий выше SQL. Естественно, он будет работать более медленно (хотя и не факт). Но над оптимизацией кода можно заставить работать компиляторы или генераторы кода. Весь поднятый шум можно по аналогии представить в следующем виде: Представим, что Вы сейчас в 60-х годах 20-го века. Все пишут операционные системы на ассемблере. Вдруг появляются какие-то пацаны. Изобретают новый язык вместо алгола и фортрана и начинают писать операционную систему для своего компьютера на этом языке высокого уровня. Какой тут поднимается шум! Блин! Какой неэффективный код же получится? Ведь на ассемблере можно все так руками оптимизировать... Бла-бла-бла... Ля-ля-ля… И что в итоге? На новом языке - Си переписали всю операционку - Unix, которая стала работать на куче разных процессоров. И до сих пор Lunix – forever ! И кто сейчас пишет операционки и приложения на ассемблере? И где все те программисты, которые ратовали за ассемблер? Поэтому, на вещи надо смотреть ширше... А к людям относиться мягше... Дуализм подхода и некоторое противоречие между объектами (объектно-ориентированным программированием) и связанными таблицами (в устоявшейся терминологии - реляционными базами данных с языком SQL) конечно есть. И это чувствует каждый программист, который пишет, используя объектный подход, но при этом использует SQL, датасеты и базы данных. Что-то здесь не то... (По крайней мере, мне так кажется). Но вводят новый уровень абстракции для того, чтобы человеку решать более сложные задачи. А рутину можно переложить на компьютеры.
	eXOR 7 Nov 2005 12:06 AM
2 Не Лох: Всех по себе не ровняйте. Под Access я вообще никогда не писал :). Все больше как-то MSSQL, да немножко Oracle. В сказку про белого бычка я не верю. Геморой был даже с тем чтобы с 8i на 9i перенести. Не говоря уж о чем-то более серьезном. Любая унификация (типа этих самых ORM) дает сразу офигенный прогиб производительности (практически теорема о сохранении ресурсов :) ). 2 злой: Школу закончили, чего и вам желаю. Ваша манера вести дискуссию доказывает отсутствие у вас качественного высшего образования. PS: Я так понимаю мнения разделились на тех, кто не понимает как работают БД, мало того не хотят этого понимать, а потому хотят спрятать их от себя за ORM, и тех кто относится к ним как к очередной мульки, любимой мышевозюкающими экс VB програмистами (ныне C# девелоперами) ;).
	ASD 7 Nov 2005 11:45 AM
2eXOR >> >>PS: >>Я так понимаю мнения разделились на тех, кто не понимает как работают >>БД, мало того не хотят этого понимать, а потому хотят спрятать их от >>себя за ORM, и тех кто относится к ним как к очередной мульки, любимой >>мышевозюкающими экс VB програмистами (ныне C# девелоперами) ;). Полностью присоединяюсь. Суть изложена верно.
	ASD 7 Nov 2005 11:52 AM
2злой Фредерик Брукс. "Серебряной пули нет." 2Сергей Тарасов (но не автор статьи) >>Естественно, он будет работать более медленно (хотя и не факт). Я имел ввиду не совсем это. Суть вопроса в том, что даже на уровне SQL statement-ов Oracle и MS SQL отличаются существенно. И приводить именно это к общему занменателю означает примитив sql логики и не испльзование всех возможностей PL\SQL и Transact SQL, а именно последнее и есть краеугольный камень быстродействия.
	злой 7 Nov 2005 12:43 PM
2eXOR Я так понимаю мнения разделились на тех, кто не понимает как работают БД, мало того не хотят этого понимать, а потому хотят спрятать их от себя за ORM, и тех кто относится к ним как к очередной мульки, любимой мышевозюкающими экс VB програмистами (ныне C# девелоперами) ;). == Все с вами ясно, вы крутой, бородатый дядька программист, все пишете на ассемблере. Вопросов больше нет. Хотя... может объясните популярность Hibernate/EJB? Или расскажите, зачем мне, девелоперу, знать тонкости всех БД? И еще расскажите, если не секрет, чем вы занимаетесь, какого рода программы пишете, если драйвера и ядра ОС, то вопросов опять же нет, вы явно не туда попали, если приложения бизнес уровня, то поведуйте на чем пишете, какие фреймворки применяете? А может вы админ БД, тогда ORM явно не для вас. ps. из личного опыта, используем хибер уже 3-и года, за это время пришлось править около 10-и запросов, котороые хибер очень криво нагенерил. В остальном, я даже не задумывался, под какую БД пишем.
	dr-Wicked 7 Nov 2005 1:18 PM
2eXOR Вот к примеру я отношусь частично к категории описанной Вами. Но в отличии от Вас почитьіваю МСДН, так на досуге. Там пару лет назад поднимался вопрос об єкстрафункциональности Н-уровневьіх приложений и связанньіми с єтим накладньіми расходами по написанию єтих самьіх уровней. Предложенній способ, а уж тем более доводьі для его использования мною не приветствуются, но следует Вам, как кулл дивелоперу, знающему такое кол-во диалектов сиквела напомнить, что большая часть архитектурьі сводится к КРУДу (по опьіту— заполнение справочников). А уж если он не кандидат на автогенерацию, то со своей стороньі Вьі будете вьіглядеть не как тот чувак с КРУТЬІМ ВИСЧИМ ОБРАЗОВАНИЕМ, а скорее как дятел, долбящий копи-пастом СЕЛЕКТ, ИНСЕРТ, АПДЕЙТ, ДЕЛИТ. ПС, Мьі знаете ли институтов не кончали, звьіняйте.
	Павел 7 Nov 2005 2:46 PM
2 >Весь поднятый шум можно по аналогии представить в следующем виде: Да какой шум? Технология эта (ORM) уже много лет широко используется. 6 лет назад сан уже выпустила спецификацию EJB 1.1 со стандартом CMP. Нормальная имплементация ORM по скорости не медленнее БД. Потому что скорость БД на порядок медленнее, чем этот ORM. Ну одно дело вытащить из хранилища хотя бы на 10000 строк какие-то данные, связать их с другой таблицей и другое создать новый объект на каждую строчку. Да с этими автобоксингами получается, что каждая сущность - объект. Число - объект. Так что накладные расходы - нулевые. Зато появляется возможность эффективно кэшировать данные, так как приложение всяко лучше знает структуру своих данных чем БД. Другое дело, что круг задач - определенный. Пока на ORM некто не возлагает задачи по аггрегации и связыванию данных. Непонятно только зачем писать статьи о том, что очень широко используется. Типа как написать, что 2*2=4.
	Павел 7 Nov 2005 2:52 PM
2 ASD >Я имел ввиду не совсем это. Суть вопроса в том, что даже на уровне SQL statement-ов Oracle и MS SQL отличаются существенно. И приводить именно это к общему занменателю означает примитив sql логики и не испльзование всех возможностей PL\SQL и Transact SQL, а именно последнее и есть краеугольный камень быстродействия. Да вам же объяснили, что ORM не заменяет хранимых процедур, а дополняет. В любом случае данные в БД надо вставлять и доставать, чтоб отобразить. И вот для этого может понадобиться ORM. Чтобы просто ходить по структурированным данным. И вообще данный спор мне кажется имеет такой сценарий: - вот вам микроскоп - гвозди забивать им очень не удобно. и дорогой. и ломается часто.
	Павел 7 Nov 2005 2:58 PM
> Фредерик Брукс. "Серебряной пули нет." У всякой пули - свое предназначение. Естественно серебряной пули нет. Но у любой технологии есть своя область применения. И только тщательное изучение этой технологии позволит выявить плюсы и минусы, область применения и скорость разработки и прочие характеритики.
	cOnst 8 Nov 2005 5:42 AM
Ребята, мы чего, книжек не читаем? Есть весьма красивая книжка Фаулера, архитектура корпоративных приложений называется. Там обозначено, в частности, 3 подхода к реализации бизнес-логики: - модель транзакции - модель таблицы - модель предметной области. Основная проблема текущего обсуждения то, что некоторые не разрганичивают последние две модели. В то же время, вторая традиционно присуща подходу от микрософт, третья - джава-подходу. ORM очень хорошо подходит для третьей модели. Область применимости, достоинства и недостатки моделей - см. книжку. На заведомо простом приложении, которое использует автор статьи, вторая модель работает хорошо. По мере же усложнения логики третий подход обеспечивает лучший ко качеству и сопровождаемости код.
	Не Лох 8 Nov 2005 6:03 AM
2 eXOR Когда я проектный диплом по теории баз данных защищал, ты пешком под стол бегал :)) ОРМ не отменяет знание SQL и принципов работы реляционной БД. Кроме того ОРМ не генерирует общий SQL код. А специфический для каждой базы. Т.е. свой родной, заточенный под Оракл, и такой же родной, заточеный под MySQL или DB2. Во всяком случае так работает Hibernate. А мнения разделились конечно. На тех кто работал со сложными и большими проектами, и тех "кто на MS SQL или Ораклом баловался" :))
	tstone - saldomail.ru 8 Nov 2005 8:59 AM
Ну вот сделали мы ОРП приложение. Все прекрасно и шоколадно. И вдруг админу потребовалось залесть шаловливыми ручками в базу данных программкой, которая на этот ОРП, мягко говоря, положила. И что получится? Прально - вся "бизьнес"-логика, так красиво упакованная в ОРП, накроется большим медным тазом. Причем уже не важно будет - обрабатывал ли он миллион записей или добавлял только одну. Что делать? Реализовывать бизнес-логику два раза - уровне ОРП и структуры БД? Или разделять на несколько уровней? А хз! Тетеоретики, блин!
	dr-Wicked 8 Nov 2005 10:37 AM
2tstone Да нет, скорее в идеале средство должно при моделировании обеспечить ссьілочную целостность средствами СУБД таким и только таким способом, что Ваш шаловливьій админ после часа секса внесёт наконец-то строку данньіх полностью удовлетворяющую приложение вцелом,… или, что скорее не сможет ввести ничего. Просто проектировать по(не?)людски надо.
	tstone - saldomail.ru 8 Nov 2005 11:45 AM
2 dr-Wicked Согласен, в идеале-то так оно. Но вроде таких еще нет, или ужо есть?
	xacid 8 Nov 2005 12:04 PM
>Реализовывать бизнес-логику два раза - уровне ОРП и структуры БД? думаю это будут две разные бизнес-логики...
	dr-Wicked 8 Nov 2005 12:42 PM
2xacid Не думаю, что "разньіе" должно опровергать мои слова. А вот когда опровергает, то получается система плохонькая. С таким успехом можно и в текстовьіх файлах данньіе хранить. 2tstone И да и нет(долгая песня). Но отрасль движется в єту сторону, что не может не радовать. На самом деле раньше по-тексту я указьівал на провальі в аргументах еХОРа. Если система работает нестабильно, то єто неозначает что её невозможно стабилизировать. Єто просто ничего неозначает.
	xacid 8 Nov 2005 5:15 PM
> Не думаю, что "разньіе" должно опровергать мои слова. А вот когда опровергает, то получается система плохонькая. С таким успехом можно и в текстовьіх файлах данньіе хранить. честно говоря ход вашей мысли для меня не очень ясен, но дело не в этом - я говорю о том что "разные" бизнес-логики означают разные задачи которые они решают сравним это с разными уровнями в операционной системе - каждый уровень решает _свои_ задачи так и тут - на уровне БД бизнес-логика решает задачи уровня БД, на уровне ОРП - задачи прикладного уровня, который о существовании БД скажем так даже не догадывается....
	xacid 8 Nov 2005 5:18 PM
кстати иногда действительно даже просто приходится хранить в текстовых файлах данные.... думаю любой кто профессионально программирует больше 5-и лет сможет подтвердить что в хранении данных в текстовом виде есть свои преимущества и иногда эти преимущества бывают важнее недостатков такого способа хранения данных... имхо конечно же
	dr-Wicked 8 Nov 2005 5:56 PM
А никто текстовьіе файльі не критиковал. Я говорил о том, что если платишь деньги за СУБД то грех неиспользовать её основньіе возможности. Насчёт ОС хорошее сравнение. Там тоже сколько файловьій дескриптор не передавай в оконную функцию ничего не получится. "Бизнес-логика на уровне БД"- я бьі не использовал такую терминологию. Лучше привести пример из жизни СиШарповой. У Вас есть таблица в Бд сотрудников. Имя Возраст Есть условие 0<Возраст<125 Каким образом протянуть ограничение на Возраст через 1. БД Таблицу 2. Процедуру Записи(интерфейсньій уровень БД) 3. ДатаСет(ДАЛ) 4. Обьект возраст(БЛ)(структура данньіх и смарт поле) 5. Елемент управления для редактирования возраста(Пользовательский интерфейс). Вот что примерно бьіло-бьі с моей точки зрения не плохонькой системой.
	xacid 8 Nov 2005 6:14 PM
а никто не запрещал использовать возможности СУБД с вашим примером тоже не вижу никаких фундаментальных проблем, если честно
	dr-Wicked 8 Nov 2005 6:41 PM
Они и не фундаментальньі. Проблема как раз в том и состоит, что необходимо продублировать очень много кода, а средств позволявших бьі мне автоматизировать єту работу я не нашёл. Не знаю Вашего стиля проектирования, но у меня очень редко появляются обїектьі бизнес-логики не отразившиеся на структуре хранения данньіх. По примеру, представьте, что необходимо заменить 125 на 126, или того хуже на 126,5. Обьём работьі может стать именно фундаментальной проблемой.
	xacid 8 Nov 2005 7:51 PM
что мешает вам определять эту константу доступной на уровне БД и использовать её же на всех остальных уровнях где это необходимо?
	Не Лох 8 Nov 2005 8:09 PM
2 tstone >>>И вдруг админу потребовалось залесть шаловливыми ручками в базу данных программкой, которая на этот ОРП, мягко говоря, положила. Во во. В тех конторах где сиквел сервер под столом у "админа" стоит, и где он ручками с данными "балуется", там никакая ОРМ не поможет. :)) Проблема в консерватории. ОРМ тут ни при чем. Если ты реализуешь бизнес логику посредством хранимых процедур, то "шаловливый" админ обойдет ее точно таким же образом - ручками :)) >>>Согласен, в идеале-то так оно. >>>Но вроде таких еще нет, или ужо есть? ОРМ полностью поддерживают декларированную в БД ссылочную целостность. Т.е. primary keys, foreing keys, defauls итд. dr-Wicked >>>Я говорил о том, что если платишь деньги за СУБД то грех неиспользовать её основньіе возможности Это смотря какие возможности. По хранению, индексированию, поиску данных, обеспечению целостности - это да. Этим нужно пользоваться, и этим ОРМ и пользуются. А вот хранимые процедуры - это архаичный сервер приложений, созданный в доисторическую эпоху когда нормальных серверов приложений не было. К функциям базы данных хранимые процедуры никакого отношения не имет. Это чужеродный довесок, пришлепнутый в виду отсутствия нормальный инструментов серверного программирования. Но в наше то время такие инстументы появились. Мощные, современные, удобные для программиста сервера приложений есть практически под все платформы. Это и J2EE для java: JBoss, BEA Weblogic, IBM Websphere etc. И Windows COM+ services от миксрософт. Игнорировать эти инструменты и продолжать писать хранимки, это все равно что игнорировать автомашины и продолжать ездить на телеге.
	fisher - raaphpclub.net 8 Nov 2005 8:20 PM
бОльшую часть минусов здесь уже назвали - когда-то мы их собрали в одном месте http://orm.net.ru/wacko/wakka.php?wakka=PlusesAndMinusesOfO rm дело было почти два года назад - лично я сейчас считаю что минусы безусловно перевешивают плюсы в по-настоящему крупных проектах
	dr-Wicked 8 Nov 2005 10:49 PM
2xacid Внимательнее посмотрите пример, мне помешало изменеие типа данньіх. 2Не Лох Не считаю хранимьіе процедурьі анахронизмом.
	Не Лох 9 Nov 2005 9:14 AM
2 dr-Wicked >>>Не считаю хранимьіе процедурьі анахронизмом. Ну вот видишь, различия в подходах выяснены. Соответственно и различия в отношении к ОРМ. Каждому свое.
	xacid 9 Nov 2005 11:36 AM
помешало изменение типа данных? насколько мне известно разумные преобразования типов данных дело вполне возможное
	dr-Wicked 9 Nov 2005 1:55 PM
2xacid ну преобразуйте байт во флоат :)
	dr-Wicked 9 Nov 2005 1:55 PM
чёрт, и обратно.
	xacid 9 Nov 2005 3:13 PM
byte b = (byte) 123; float f = (float) b; b = (byte) f;
	Веселый - dinaz_78mail.ru 10 Nov 2005 5:40 PM
2 Не Лох Как только твоя база перевалит за несколько лимонов записей, то ты поймешь , что без хранимых никуда. Использовать надо и ORM и хранимые для получения хороших результатов
	dr-Wicked 10 Nov 2005 7:25 PM
2xacid смешно:)
	xacid 10 Nov 2005 7:53 PM
мне тоже
	Не Лох 10 Nov 2005 9:58 PM
2 Веселый Да я уже столько лет работаю с большими БД. В сотни миилионов записей :)) Может расскажешь какие это у меня возникнут проблемы ? Что мне прямо так жутко понадобятся хранимки ? Я имею в виду конечно хранимки для БИЗНЕС ЛОГИКИ, а не пакетной обработки миллионов записей. Ты надеюсь пронимаешь что бизнес логика оперирует с небольшим количеством взаимосвязанных обьектов. Пакетная же обработка большого числа записей является maintenance. Т.е. непосредственно к разрабатываемому приложению для пользователя, отношения не имеет. Для подобного типа работ можно (и нужно) пользоваться хранимками. Количество их при этом небольшое и переносить их нет нужды. А если даже и есть, то нетрудно (из за небольшого количества). Приведи пример использования хранимок, работающих с миллионами записей, в пользовательском приложени :))
	xacid 10 Nov 2005 10:51 PM
мой последний проект состоял из 80% sql пересчет занимал времени до 20 минут
	xacid 10 Nov 2005 10:52 PM
пересчет естественно на sql не на sql был только юзерский интерфейс
	xacid 10 Nov 2005 10:53 PM
очень сложные были правила рекурсивной обработки деревьев в базе данных курсорами
	xacid 10 Nov 2005 10:55 PM
но ормы нужны хотя бы для юзерского интерфейса имхо
	xacid 10 Nov 2005 10:55 PM
и sql я считаю тоже надо генерировать
	ORM 11 Nov 2005 9:12 AM
Послушайте господин Тарасов, вы ешё не сталкивались с иерархическими изменениями и их (частичным/полным) откатом в offline'е. Так вот, что-бы это сделать с объектами надо прилично погиморроится, а в ADO.NET раз плюнуть (CancelEdit/Reject)
	Не Лох 11 Nov 2005 8:16 PM
Послушайте господин ОРМ. Hibernate прекрасно справляется с иерархическим деревом обьектов, а также с транзакционностью (откаты). Ты можешь создавать любое количество взаимосвязанных обьектов. А затем записать их в базу одной командой. При ошибке Hibernate грамотно откатит все назад. При этом все автоматом, т.е. никакого геморроя, в том числе и ado.net-овскими (CancelEdit/Reject) Более того - Чем сложнее иерархия обрабатываемых обьектов, и чем их больше, тем больше выгода от использования ОРМ, по сравнению с голым ado.net Так что судя по всему это ты не сталкивался с иерархическими изменениями.
	xacid 12 Nov 2005 1:39 PM
в postgreSQL stored procedures можно на java делать
	Андрей - supportlastcomponent.com 12 Nov 2005 8:58 PM
Почему в Яве применяют ОРМ - потомучто там нет DataSet. Почему в .NET не применяют массово ORM - потомучто есть DataSet! В чем проблема с ORM и .NET?? Зачитать объекты и сохранить их это пол дела, для программы с ГУИ эти объекты надо еще и отобразить! И тут никакой ОРМ не поможет. .NET GUI Заточены на DataSet а не на объекты!!! И что делать??? Не хочет ли автор привести пример кода как биндить объекты к ГУИ? Уверен, что такой пример будет выглядеть также криво как приведенный код с заполнением датасета. .NET же при совершенно кривых способах заполения и сохранения дата сета дает уникальные ГУИ возможности для его отображения, какие Яве и не снились. Так что же делать?? А ответ прост - пишешь логику то используй ОРМ. Делаешь ГУИ - Датасет. А если то и другое, тут то и начинается ФИЛОСОФИЯ!
	Андрей - supportlastcomponent.com 12 Nov 2005 9:09 PM
А вот тут пара моих мыслей как объединить ОРM и DataSets в один паттерн для .NET 2.0 http://www.lastcomponent.com
	xacid 13 Nov 2005 3:28 PM
интересно как ваши .NET GUI помогут реализовать сложную бизнес-логику? на sql программировать - занятие не для слабонервных
	Андрей - supportlastcomponent.com 13 Nov 2005 3:49 PM
Я и говорю, что паттерны надо комбинировать в зависимости от задачи. Нет однозначного ответа.
	Не Лох 13 Nov 2005 9:30 PM
2 Андрей >>>И тут никакой ОРМ не поможет. .NET GUI Заточены на DataSet а не на объекты!!! Вообще то .NET GUI заточен не под DataSet а под интерфейс, который позволяет им работать с любым списком обьектов, в том числе и с DataSet. Таким образом можно приатачить все эти эжт боксы и гриды к коллекции обьектов, возвращаемой ОРМ, точно также как ты это делаешь с DataSet. Т.е. абсолютно никакой разницы. Просто ты кроме Dataset другими коллекциями обьектов никогда не пользовался. Отсюда у тебя и мнение что кроме Dataset ничего к контролам приатачить нельзя. :))
	Андрей - supportlastcomponent.com 13 Nov 2005 10:09 PM
2 Не Лох. Я не сказал, что нельзя! Я сказал что не так уж и просто. Датасет биндится к контролам дезайнером и по умолчанию. Для того чтобы прибиндить коллекцию надо писать код ручками. И разница велика!! Никакой контрол не будет валидировать длинну срок или проверять на НУЛЛ поля объектов, как это делает любой контрол с датасетом. Никакая коллекция не позволит делать undo. и проверять foreign constraints. DataSet я набрасаю дезайнером за 2 минуты, а что я должен делать с коллекциями?? А как биндить репорты которые не отображают объектный мир 1:1, а являются агрегацией или джойнами? Дата сет наиболее удобный способ работы с ГУИ. ОРМ - с бизнесс логикой. Я ни с кем не спорю. А просто хочу сказать что нет однозначного решения. Биндить бизнесс объекты к ГУИ всеравно не верно, так как бизнес логика не должна быть доступна клиенту. Бизнес логика должна лежать на сервере или в бизнес компонентах. Биндить к ГУИ надо дата контейнеры, и датасет очень удобен для этого. Зачем изобретать велосипед?
	Не Лох 14 Nov 2005 12:30 AM
2 Андрей >>>Я не сказал, что нельзя! Я сказал что не так уж и просто. Было непросто. В dotnet 2 появился класс ObjectView аналог DataView. Вот его можно прямо из вижуал дезайнера байндить к контролам. >>>Никакой контрол не будет валидировать длинну срок или проверять на НУЛЛ поля объектов, Почему не будет ? Hibernate проверяет как длину полей так и NOT и другие constrants. Не сам обьект проверяет конечно, а Hibernate, работая с этим обьектом. Причем инфу а размере поля и о NOT NULL он также как и Dataset берет автоматом из БД. Датасет отличная вешь для табличных отчетов. Но когда нужно создасть сложную форму ввода со многими master-detail связями, и чтобы транзакционность поддерживалась, тут сталкиваешься с тем что все это ручками надо делать. ОРМ все это делает автоматом. Таким образом основное применеие ОРМ - это сложные формы ввода информации. А для отчетов и простеньких форм для заполнения одной таблицы конечно Dataset - самое то. Каждому инструменту - свое место.
	Андрей - supportlastcomponent.com 14 Nov 2005 7:59 AM
2 не ЛОХ >>Датасет отличная вешь для табличных отчетов. Но когда нужно создасть сложную форму ввода со многими master-detail связями, и чтобы транзакционность поддерживалась, тут сталкиваешься с тем что все это ручками надо делать. ОРМ все это делает автоматом. Да в том то и дело, что ОРМ проверит это все на стадии записи в БД, а дата сет еще в ГУИ без лишнего обращения к БД. Когда делает это Hebitnate?? Когда я начинаю сохранять?? Прелесть датасета в валидациях на стадии ввода, а не на стадии сохранения! Что я должен делать в клиент-сервер апликации?? После каждого ввода просить сервер провалидировать не ввел ли я где в поле? Зачем нагружать Hebirnate? Ему и так есть чем заняться - персистенцией. >>Таким образом основное применеие ОРМ - это сложные формы ввода информации Если вы пишите не простенькую АСП страницу, а сложное client-server приложение с различными клиентами: winforms/webservices то отдавать бизнесс объекты для биндингу клиенту нельзя, хотя бы из соображения безопасности (клиент не должен имет доступ к CLR коду бизнесс логики). Так что я не представляю как можно применять ОРМ в совокупности с GUI. Наверное только в АСП, где кстати GUI очень примитивны и ни окакой сложности и говорить не стоит. >>Послушайте господин ОРМ. Hibernate прекрасно справляется с иерархическим деревом обьектов, а также с транзакционностью (откаты). Позволю ответит себе и на этот вопрос. Речь шла об off-line откатах, а не откатах ТРАНЗАКЦИЙ!! Автор видимо действительно не знаком с темой. Попробую пояснить: Если произошло исключение в бизнесс лейере, то клиент может решить сделать UNDO на часть информации используя RejectChanges без дополнительного опроса бизнесс лейера, что приведет к возвращению клиентского экрана в первоисходное состояние. Что делать с объектами? Просить бизнес лейер перезагрузить данные? И это все ручками? Не надо пвтаться привинтить ОРМ туда куда он не подходит. Оставьте его для сервера и бизнесс логики.
	Не Лох 14 Nov 2005 8:42 AM
2 Андрей. >>>Когда делает это Hebitnate?? Зачем придумывать ? Все проверки Hibernate делают ДО обращения к серверу. >>>Просить бизнес лейер перезагрузить данные? И это все ручками? Ну вот опять. Зачем придумываешь ? Ты обсуждаешь вешь которую в глаза не видел. И заранее навешиваешь на нее удобные для тебя "недостатки" чтобы потом самого же себя убедить в правильности и единственности своего выбора :)) Hibernate прекрасно сохраняет старые данные и откатывается на них без всякого обращения к серверу. :)) Ты пойми, тебе продать никто ничего не пытается. Доволен датасетами, так пользуйся ими. Я датасетами недоволен, поэтому ищу тулзу которая решает мои проблемы. И много другого народу ищет. Потому и появляются ОРМ. И обсуждение это предназначено для тех кто недоволен датасетами. Ты вот доволен - ну так иди своей дорогой, че ты здесь окалачиваешься ? :))
	Андрей - supportlastcomponent.com 14 Nov 2005 9:08 AM
2 не ЛОХ. Извини, я сразу не понял что сдесь сидят только те кто доволен ОРМ - мами. Если так пойду действительно туда где ими не довольны. :-) Кстати я ОРМ-ми доволен и Датасетами доволен и замечаительно приминяю и то и это на практике. И не пытаюсь навязать никому или то или это. Правда - по середине.
	Не Лох 14 Nov 2005 9:28 AM
Ну тогда раскажи что это за ОРМ ты применяешь и на какой практике :)) А то по твоим "догадкам" о недостатках ОРМ у меня сложилось впечатление что ты их никогда не видел.
	Андрей - supportlastcomponent.com 14 Nov 2005 9:51 AM
Nhebirnate - был отметен мной 2 года назад, именно из-за проблем описанных выше (или ниже) и из-за тогдашней его альфовости. OJB.NET - был выбран и применялся успешно, но с большими переписками и дописками. Поэтому могу сказать, что я не по наслышке, а от первого лица знаю какие проблемы несет ОРМ и какие он решает (проблемы я попытался изложить в первую очередь - GUI). Если Вас интересуют размеры проектов - то это Client/Server ~ 300 таблиц, WinForms GUI (~100 форм, ~1500 User controls), WebServices. ~30 разработчиков. ~ 900000 срок кода, где наверное 70% генерированный код. И еще раз ОРМ приминять надо, но разумно, там где это оправдано. Ну а если вы посмотрите на мой 2-й топик, то поймете что я делаю сейчас. И что об ОРМ я знаю не по наслышке. А ругаться в форуме не к чему. Мы же дискутируем, чтобы понять истину и где каждый может для себя вынести полезную информацию и в итоге писать код для заказчиков быстрей и надежней.
	Не Лох 14 Nov 2005 10:11 AM
>>>И еще раз ОРМ приминять надо, но разумно, там где это оправдано. О чем вобщем то говорит и автор статьи и я неоднократно. Чего же мы с тобой спорим то ? Или ты не просек что именно об этом статья, и решил что тут ОРМ пихают во все дыры, независимо от того лезет оно туда или нет ?
	Андрей - supportlastcomponent.com 14 Nov 2005 10:15 AM
2 Не Лох >>Или ты не просек что именно об этом статья, и решил что тут ОРМ пихают во все дыры Да нет, просто автор выложил не очень удачный пример с Датасетами. Я конечно понимаю, что это "Маркетинг", ну вот и решил вставить свои 2 копейки в защиту DataSet.
	Не Лох 14 Nov 2005 10:20 AM
2 Андрей >>>OJB.NET - был выбран и применялся успешно, но с большими переписками и дописками. Поэтому могу сказать, что я не по наслышке, а от первого лица знаю какие проблемы несет ОРМ Ууу понятно откуда у тебя такая неприязнь к ОРМ :)) Недостатки конкретного продукта считаешь недостатками самого подхода ОРМ. Прими мои соболезнования. OJB под java это такая мерзкая весчь. Судя по всему gdotnet-овский это порт, со всеми его недостатками. Основным является требования всех обьектов реализовывать кучу интерфейсов, намертво привязывая теюя к этой библиотеке. Потом коллекции которые он создает не реализуют стандартных интерфейсов. Поэтому ты не можешь их байндить к контролам. Опять же судя по твоим жалобам, он не откатывает на старые значения при ошибке. Понятно короче. Советую опять попробовать NHibernate
	Андрей - supportlastcomponent.com 14 Nov 2005 10:29 AM
2 Не Лох. К счастью мне уже не надо ничего пробовать. Могу тебе самому предложить попробовать вот это: http://www.lastcomponent.com А вот тут пара мыслей как писать Query без SQL и HQL: http://www.lastcomponent.com/downloads/pdsinaction.wmv
	Андрей - supportlastcomponent.com 14 Nov 2005 10:35 AM
По поводу выбора OJB.NET 2 года назад NHebirnate был в противозачаточном состоянии а OJB.NET был практически полностью спортирован. Сейчас ноборот, но решение надо было применять 2 года назад.
	Коляныч - kolanychmail.ru 14 Nov 2005 2:13 PM
>в postgreSQL stored procedures можно на java делать< >на sql программировать - занятие не для слабонервных< вобщем я понял этого товарища - есть категория людей, не способных понять сиквел в принципе, хотя с процедурными языками/ооп у них нередко все в порядке ... ну не укладывается у них в голове, что сиквел оперирует множествами, а не отдельными переменными. отсюда и попытки писать код в бд на жабе или .нет, сплошные курсоры и вымученные селекты... в итоге жуткие тормоза. ничего личного, просто голова у них так устроена...
	Не Лох 14 Nov 2005 8:47 PM
>>>Могу тебе самому предложить попробовать вот это: http://www.lastcomponent.com Так это и есть ОРМ. Кстати мне он не понравился. Слишком много писанины. Hibernate гораздо легче в использовании. Во вторый он тоже заставляет (вернее генерирует для тебя) бизнес обьекты со своими интерфейсами, т.е. привязывает тебя намертво к своей библиотеке. Одно из преимуществ Hibernate заключается в том что твои бизнес обьекты понятия не имеют ни о каком ОРМ. Т.е. завтра ты можешь поменять Hibernate на что нибудь другое и не придется переписывать ни строчки в твоих бизнес обьектах. В любом случае и ты и я - мы нашли решение своих проблем. И это ОРМ, пусть и разные продукты.
	Андрей - supportlastcomponent.com 14 Nov 2005 8:54 PM
2 - Не Лох Ну насчет не надо переписывать ни строчки - переписывать всегда надо. Например - запросы! А насчет сложности - пример в студию. Я свой пример выложил. Зачем голословно поливать грязью. Можно легче - покажи пример. А вообще все дело вкуса и хорошо, что пользователю есть из чего выбирать!! :-)
	Не Лох 15 Nov 2005 2:56 AM
Кто же грязью то поливает :)) Ну ты даешь. Я просто сказал что простые операции типа подсоединения к БД или запроса, пишутся на этом lastcomponenet слишком многословно. Причем copy-paste кода с твоего AVI файла сделать не могу :)) Вот как открывается сессия в Hibernate: session = nh.factory.OpenSession(); Сравни с кодом приведенным в твоем примере. :)) Вот как загружается обьект по id: myCust = (Customer)nh.Session.Load(typeof(Customer), 123); Вот как идет запись в БД всех обьектов, какие были изменены, удалены, добавлены : nh.Session.Flush(); Вот запрос: myCustomers = nh.Session.Find("from Customer c where c.CustomerName like ? order by c."+SortBy, edtCustomer.Text+"%"); А теперь ты давай пример приводи. Только на этот раз не надо avi :))
	Андрей - supportlastcomponent.com 15 Nov 2005 7:52 AM
2 Не Лох. Я не собираюсь заниматься тут маркетингом, Ты действительно не уловил смысла в чем разница между untyped кодом и typed кодом? Посмотри на пример который ты сам приводишь, в нем 3 места которые ведут к потенциальным ошибкам: 1) session = nh.factory.OpenSession(); Session надо закрыть. А что будет если exception? Будешь try catch писать? try { session = nh.factory.OpenSession(); } finally { nh.factory.CloseSession(); } сравни: using(TransactionContext ctx = new TransactionContext()) { } Контекст сам закроется, даже если Exception. Кстати есть ботдержка бизнесс сервисов, где мето бежит в сессии и ни надо вообще ее открывать и комитить, все делается само! Сравни: [Transactional] public void BusinessMethod() { Customer cust = model.Customers.Fill(1); cust.Name = "Test"; } 2)myCust = (Customer)nh.Session.Load(typeof(Customer), 123); А если я опишусь? Customer myCust = (Order)nh.Session.Load(typeof(Customer), 123); Сравни: //Опиаться нельзя Customer cust = model.Customers.Fill(1); 3) Самое главное! myCustomers = nh.Session.Find("from Customer c where c.CustomerName like ? order by c."+SortBy, edtCustomer.Text+"%"); HQL ни чем не лучше SQL. HQL - untyped. И является прямым источником ошибок, потому что его нельзя проверить компилятором! Тоже что я показал в авишке, это typed язык запросов, который проверяется компилятором! А насчет авишек, я специально положил. Вот видишь тебе лень пойти на сайт и посмотреть примеры, которых там куча! Ну а авишку хоть посмотрел. Я ничего не имею против Hebirnate. И каждый выберет то что ему по душе. Я так же всячески уважаю людей, которые занимаютя open-source проектами и не имеют от этого выгоды! Я просто привел пример библиотеки которая дает определенные приемущества. А главное из них, она не уперта в ОРМ и дает возможность работать людям которые любят только DataSet и не хотят никакого ОРМ.
	xacid 15 Nov 2005 1:36 PM
>вобщем я понял этого товарища - есть категория людей, не способных понять сиквел в принципе, хотя с процедурными языками/ооп у них нередко все в порядке ... ну не укладывается у них в голове, что сиквел оперирует множествами, а не отдельными переменными. отсюда и попытки писать код в бд на жабе или .нет, сплошные курсоры и вымученные селекты... в итоге жуткие тормоза. ничего личного, просто голова у них так устроена... вам пора к доктору причем здесь моя голова если в базе данных в великом множестве присутсвуют древовидные структуры данных? ну ка изобразите рекурсивную обработку дерева на sql без курсоров? может лучше будете хотя бы немного думать перед тем как делать выводы какие-то? ничего личного, просто вы пукнули в лужу
	xacid 15 Nov 2005 1:40 PM
>Ты действительно не уловил смысла в чем разница между untyped кодом и typed кодом? помоему карент топик у нас не "в чем разница между untyped кодом и typed кодом?" а "ОРП (ORM): зачем это нужно?" вот "нравяца" мне такие "дискуссанты" которые с пеной у рта вдруг сьезжают на какие то неотносящиеся к теме вопросы и начинают что то доказывать даже если с ними никто не спорит опять же - ничего личного
	xacid 15 Nov 2005 1:49 PM
> отсюда и попытки писать код в бд на жабе или .нет, сплошные курсоры и вымученные селекты... экслкюзивно для вас цитирую себя же: мой последний проект состоял из 80% sql поясняю что это значит: это значит что абсолютно вся обработка данных производится исключительно на sql в хранимых процедурах ночью по шедулеру запускается на выполнение таск который в течении десяти-пятнадцати минут пересчитывает базу задача - MRP надеюсь знаете что это такое это к вопросу знания sql тем не менее я считаю что _разумное_ использование объектных отображений базы данных на модель предметной области - дело нужное и полезное
	REvilest - REvilestmail.ru 15 Nov 2005 1:54 PM
сори, вопрос к 2 не лох
	Андрей - supportlastcomponent.com 15 Nov 2005 3:09 PM
2 xacid Как раз потому что автор татьи привел пример работы с untyped dataset, а мог бы привести typed и не было бы никакой видимой разницы.
	Yuri Abele 15 Nov 2005 6:04 PM
eXOR > 2 злой: eXOR > Школу закончили, чего и вам желаю. Ваша манера вести eXOR > дискуссию доказывает отсутствие у вас качественного eXOR > высшего образования. ... eXOR > любимой мышевозюкающими экс VB програмистами eXOR > (ныне C# девелоперами) ;). О, но тут высшее образование просто через края хлещет! Первый признак общей недалекости - попытки обобщения
	Не Лох 15 Nov 2005 9:02 PM
2 REvilest Я работаю на java. Поэтому пользуюсь Hibernate dotnet просто баловался, пару книжек прочитал, да небольшую программу написал, просто чтобы поучиться. Естественно использовал NHibernate, потому что Hibernate я уже знаю, т.е. переучиваться не надо. 2 Андрей Typed queries это круто конечно. В Hibernate этого нет, согласен. Однако с появлением DLinQ от МС ситуация изменится. И тогда я смогу работать на NHibernate и иметь typed queries.
	Вася 16 Nov 2005 9:05 AM
2 НЕ Лох >>dotnet просто баловался, пару книжек прочитал, да небольшую программу написал, просто чтобы поучиться. Так чего ты тут мозги все париш? Давай я тебе еще книгу дам по .NET и ты успокоишься. А то трендит как заведенный Hebirnate, Hebirnate. То-то я смотрю парень муть несет какую-то. Ты может и по яве тока пару книг прочел???
	Павел 16 Nov 2005 9:36 PM
2 Коляныч: >есть категория людей, не способных понять сиквел в принципе, хотя с процедурными языками/ооп у них нередко все в порядке ... ну не укладывается у них в голове, что сиквел оперирует множествами, а не отдельными переменными. отсюда и попытки писать код в бд на жабе или .нет, сплошные курсоры и вымученные селекты... в итоге жуткие тормоза. ничего личного, просто голова у них так устроена...
	Павел 16 Nov 2005 10:22 PM
2 Коляныч: сорри, рука сорвалась :). к сожалению не вся бизнес логика может уместиться в простой сиквел. Собсно сам сиквел есть набор нашлепок. Иначе я например не могу объяснить себе такую сильную разницу в семантике различных комманд - почему например insert и update так сильно различаются. Именно поэтому во всех приличных БД есть встроенные процедуры. Нашлепка на SQL, но необходимая. А поскольку это (встроенные процедуры) нашлепка, то она тоже несовершенна. Например есть такое простое правило: использовать как можно меньше языков. Потому что проще поддерживать, легче разбираться и так далее. А тут получается половина бизнес логики на одном языке (встроенные процедуры), половина на другом. А зачем нужны встроенные процедуры - не всегда по скорости SQL справляется. Вот например задача - считать число кликов и просмотров в баннерной сети. Казалось бы раз плюнуть. На практике количество кликов - много миллионов в день, число просмотров вообще немерянное. А база - одна (потому что денег столько есть). Приходится сначала данные складывать в одну таблицу, потом агрегировать, перекладывать, удалять. Если одним запросом - то долго. Свалится в середине и все, заново начинай. А данные все прибывают :). Потом надо обсчитывать не только количество, но и группировать по клиентам и разным параметрам и комиссию считать. И отображать. А отображать так просто тоже не получается потому что медленно, поэтому тоже делается аггрегация. Ну и так далее. И денормализация тоже в реальных проектах довольно частое дело. Ну и запросы динамически составлять - во встроенных процедурах это как правило сделать нельзя. Короче практика имеет расхождение с теорией. И практика показывает, что это нужно. А критерием истинности как известно является практика. Это еще дедушка Ленин говорил.
	Коляныч - kolanychmail.ru 18 Nov 2005 7:46 AM
>к сожалению не вся бизнес логика может уместиться в простой сиквел.< возьмите не простой (майскуль), а развитой (оракл/мс сиквел) >получается половина бизнес логики на одном языке (встроенные процедуры), половина на другом< идти читать по к/с архитектуру и многозвенки, а потом уже писать "80% sql" в проекте. причем вместе с "архитектором" Тарасовым... >А зачем нужны встроенные процедуры - не всегда по скорости SQL справляется< знаем, проходили, "сами напишем лучше"... >Приходится сначала данные складывать в одну таблицу, потом агрегировать, перекладывать, удалять. Если одним запросом - то долго< ага, долго, написать group by, мы лучше сами агрегирование замутим в 10 вложенных циклах на тысячах строк кода, нам за это деньги платят... вообще "складывать/перекладывать/удалять" с головой выдает вас как человека, абсолютно не понимающего sql, диагноз тот же >Свалится в середине и все, заново начинай.< идти читать про транзакции ... >Ну и запросы динамически составлять - во встроенных процедурах это как правило сделать нельзя. < идти читать про exec/sp_executesql, а также к ораклистам, они тоже что-то посоветуют. а вообще динамические запросы - плохой стиль и дополнительные пробемы с секурностью
	Sephirot 18 Nov 2005 12:03 PM
2 Андрей Посмотрел на Ваш мультик (http://www.lastcomponent.com/downloads/pdsinaction.wmv). Прикольно, на DLINQ похоже. Рефакторинг точно упроститься должен во многом. А чего у Вас под студию beta 2 только? У меня релиз давно стоит уже.
	xacid 18 Nov 2005 2:48 PM
кальяныч, ты с кем разговариваешь? такое впечатление что сам с собой... сам себе советы даешь.... я тоже могу тебя куда нибудь послать если хочеш ты кроме невнятного бормотания можеш что нибудь по делу сказать? что конкретно тебя не устраивает? без рассуждений о чьих то предполагаемых недостатках и таких же предполагаемых пробелах в образовании или без этого негативы мысли не склеиваются? ну тогда научись сначала мысли связывать а потому же вмешивайся во взрослые разговоры
	xacid 18 Nov 2005 2:50 PM
делок нашелся лечит в сад
	xacid 18 Nov 2005 3:19 PM
да, кальяныч, один ты у нас образованый, интеллигентный, всё знаешь а мы сирые, во тьме невежества погрязли и даже не понимаем ничего особенно sql-я ну ниче, ты не волнуйся, скоро все прозреют (с твоей помощью) и на поклон к тебе лично и к твоим гуру потянуца.... ты жди тока этого скоро уже
	eXOR 22 Nov 2005 12:59 AM
2 Yuri Abele: Я надеюсь вы внимательно прочли то, что написали :).
	Павел 24 Nov 2005 2:16 PM
2 Коляныч: >возьмите не простой (майскуль), а развитой (оракл/мс сиквел) развитой сиквель - это уже не сиквель, а попытка скрестить язык работы с данными и процедурный язык. >идти читать по к/с архитектуру и многозвенки, а потом уже писать "80% sql" в проекте. причем вместе с "архитектором" Тарасовым... Почему, можешь сказать? Я тебе привел вполне конкретный пример, когда бизнес логика по вполне понятным причинам (быстродействия, расход памяти, устойчивсоть) не может быть реализована на читстом SQL. С чем именно скрещивать SQL на самом деле все равно. Но было бы логичнее уж если на то пошло скрестить с чем-то, что уже используется в основном проекте. По причине того, что легче поддерживать. А ты выкрикиваешь какую то х..ю. Либо приведи свои доводы, либо в сад. >ага, долго, написать group by, мы лучше сами агрегирование замутим в 10 вложенных циклах на тысячах строк кода, нам за это деньги платят... дурак ты. я же тебе объясняю, именно с чистого SQL group by пришлось переползать на функции из-за того, что работало слишком медленно, ело много памяти. Эх, жаль коляныча не было - он бы пришел и одно его присутствие заставило бы базу крутиться раз в 20 быстрее. А то и в 30!
	dr-Wicked 25 Nov 2005 10:46 AM
2Павел В отношении использования SQL считаю что коляньіч прав, так же как и Вьі во фразе >Эх, жаль коляныча не было - он бы пришел и одно его присутствие заставило бы базу крутиться раз в 20 быстрее. А то и в 30! Для денормализации данньіх используют дополнительньіе OLAP средства.Группировка операция не бьістрая, но оптимизатор запросов, полагаю даже простой субд, как мускул, должен построить более оптимальньій план исполнения, чем Вьі, хотя бьі потому, что данньіе Вьі в любом случае получаете от субд, следовательно накладньіе расходьі по трансляции бинарньіх данньіх в драйвер субд уже присутствуют. В противном случае, Вам данная субд просто не подходит. Достаточно редко встречаются сложньіе комплексньіе алгоритмьі одновременно над скалярньіми и векторньіми величинами. Но в єтом случае можно порекомендовать использование внешних хранимьіх процедур. По поводу приведённого примера, динамическое исполнение запросов и группировка в них, отвечу собственньім афоризмом пятилетней давности: "Чуваки пьітались добиться максимального торможения, но Явьі не знали". C"MSSQL BOL"-EXECUTE: Statement(s) inside the EXECUTE statement are not compiled until the EXECUTE statement is executed. По поводу с чистого SQL group by пришлось переползать на функции из-за того, что работало слишком медленно, ело много памяти Одна из причин популярности использования SQL єто оптимизированная обработка массивов данньіх не умещающихся в оперативной памяти. Обьічно SQL сервера имеют собственньіе менеджерьі кеша и расширенное управление памятью.
	катя - moska.91mail.ru 13 Dec 2005 7:21 PM
я хочу получить образование дизайнера что для этого нужно?
	катя - moska.91mail.ru 13 Dec 2005 7:24 PM
ф если сначало поступить в художественное училище это мне поможет при поступление на дезайнера?