Изменения

Пример: http://rutube.ru/tracks/793494.html - доклад с YAPC::Russia. Автор — Егор Шиповалов, название «Применение ORM в Perl». Первый же слайд ясно даёт понять проблемы, обычно решаемые с помощью авторами объектно-реляционных мапперовв Perl’е:

Строго говоряТак вот, всё это все эти причины — «[[lurkmore:4.2|4ёрта.с4.2(чёрта с два)]]». Тривиальный Бесплатная подсказка, тривиальный путь решения всех трёх проблем: код работы с БД для каждого «компонента» программы выносится в отдельный класс и разбивается на отдельные процедуры. При грамотном разбиении кода работы с БД на отдельные процедуры он получается достаточно компактным, а если не компактным, то по меньшей мере простым и очевидным. Весь код работы с БД таким образом становится сконцентрирован концентрируется в одном месте, и переписывать под различные СУБД его становится гораздо проще. И уж конечно, имея код работы с БД в отдельном классе, неспециалисты по БД могут и не заниматься работой с ней. Между прочим, этот подход использует [http://www.skype.com/ Skype], за тем исключением, что функционал в процедуры они оборачивали не на стороне клиента БД, а внутри самой СУБД ([http://www.postgresql.org/ PostgreSQL]) — об этом Иван Золотухин рассказывал в статье «[http://postgresmen.ru/articles/view/25 Масштабирование PostgreSQL: Готовые решения от Skype]».

Есть и сложный путь — использование языка запросов типа [[rupediaЕщё одна почти бессмысленная для веб-приложений возможность:Language_Integrated_Queryитераторы. Даже {{CPAN|LINQ]] или [[Funq]]DBR}} её, кстати, не лишён. То есть она осмысленная — в GUI-приложениях. Ради решения этих трёх проблем они Но не в веб-приложениях, где, во-первых, сам DBI никогда не держит открытых курсоров, во-вторых, это часто не даёт делать СУБД, а в-третьих, это совершенно не нужно, так как время исполнения запроса должно быть как можно меньше, а следующий запрос, вероятно, попадёт в другой поток — а может, и был задуманывообще в другой процесс.

Тем не менее, ORM’а всё равно хочется. Даже Bugzilla имеет своё подобие ORM’а. ''Почему?'' А вот некоторый Небольшой обзор существующих модулей ORM:

А вот ещё одна почти бессмысленная возможность: итераторы== Реальная проблема == Реальная проблема, ради решения которой задуман ORM — сложность, возникающая при попытке организовать сохранение в БД кучи различных объектов '''разных типов''' со '''сложными отношениями''' друг между другом.  Даже {{CPAN[[lib:Bugzilla|DBR}} её, кстати, не лишёнBugzilla]] имеет своё подобие ORM’а. То есть она осмысленная — И причина именно в GUI-приложенияхэтом — нужно управлять многими типами объектов. Но не в веб-приложенияхУ бага много атрибутов, где сам DBI, во-первых, никогда не держит открытых курсоров, во-вторых, это часто не даёт делать СУБДдля каждого атрибута заведён отдельный тип «поле», а в-третьихнекоторые из этих типов одновременно являются самостоятельными объектами (продукты, это совершенно не нужно, так как время исполнения запроса должно быть как можно более малым, а следующий запрос уже вряд ли попадёт в тот же поток (или вообще процесскомпоненты).