?

Log in

No account? Create an account
tech

ORM

Вчера мы немного праздновали, беседовали по-разному :) жаловались на жизнь, как водится. Одна из любимых тем на что можно пожаловаться это работа базы данных и ООП. Object Relational Mapping. Был предложен вот такой подход:
http://forum.agiledev.ru/index.php?t=msg&th=981&start=0&

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

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

BTW, интересная статья:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Comments

Дмитрий, по первой ссылке вижу не ORM, а подход EAV к хранению данных, многократно обсосанный на SQL.ru, со всеми плюсами и минусами. На нём можно строить ORM, но не обязательно.

Интересно, что вам мешало отформатировать запрос в читаемую форму с синтаксисом соединений по ANSI?

А вы имеете какое-то отношение к самому ресурсу AgileDev.ru?
Спасибо за ответ, Денис.

Можете дать ссылку на обсуждение на sql.ru? Я потому и задал вопрос, что такой подход видимо должен приходить в голову, тем более что я вижу это не первый раз.

Это у меня был пример на Access, того, как это можно реализовать. Я его просто взял как есть, даже не думал о форматировании.

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

Насчет AgileDev.ru -- я люблю там бывать и общаюсь там где-то год, как раз с того момента, как стал использовать TDD и делать шаги к паттернам проектирования. Могу сказать, что мне там нравится и я поддерживаю дружеские отношения с основателями. Но к компании BIT и проекту LIMB я отношений не имею, по крайней мере пока.
В википедии есть короткая справка :)
http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

Но если дадите ссылку на содержательное обсуждение, буду благодарен.
В гугле по "ANSI syntax join":
http://www.dba-oracle.com/oracle_news/2004_2_19_rittman.htm

Для вашего запроса это будет выглядеть так:
CREATE SYNONYM I FOR Items;
CREATE SYNONYM IT FOR ItemTypes;
CREATE SYNONYM IV FOR ItemValuesAnotherItemID;

SELECT Composer.ItemName,
       Music.ItemName,
       Carrier.ItemName,
       MediumTypes.ItemTypeName,
       CarrierTypes.ItemTypeName

  FROM I AS Composer

  JOIN IV AS MusicsComposer
    ON MusicsComposer.AnotherItemID = Composer.ItemID
   AND MusicsComposer.DataTypeID    = 6

  JOIN I AS Music
    ON MusicsComposer.ItemID = Music.ItemID
   AND Music.ItemTypeID      = 12

  JOIN IV AS AlbumsMusic
    ON AlbumsMusic.AnotherItemID = Music.ItemID
   AND AlbumsMusic.DataTypeID    = 11

  JOIN I AS Album
    ON AlbumsMusic.ItemID = Album.ItemID
   AND Album.ItemTypeID   = 8       

  JOIN IV AS MediumsAlbum
    ON MediumsAlbum.AnotherItemID = Album.ItemID
   AND MediumsAlbum.DataTypeID    = 7

  JOIN I AS Medium
    ON MediumsAlbum.ItemID = Medium.ItemID

  JOIN IV AS MediumsCarrier
    ON MediumsCarrier.ItemID     = Medium.ItemID       
   AND MediumsCarrier.DataTypeID = 8       
  
  JOIN I AS Carrier
    ON MediumsCarrier.AnotherItemID = Carrier.ItemID
   AND Carrier.ItemTypeID IN (1,2)

  JOIN IT AS MediumTypes
    ON MediumTypes.ItemTypeID = Medium.ItemTypeID

  JOIN IT AS CarrierTypes
    ON CarrierTypes.ItemTypeID = Carrier.ItemTypeID
  
 ORDER BY Composer.ItemName, Music.ItemName;
Спасибо!
Первое похоже на хранение одной записи не строками, а столбцами, что есть очень гнусно. Когда можно было бы выбрать данные из одной таблицы, придется выбирать из пяти. И сфера применения, думаю, должна быть не в ОРМ, а в каком-нибудь искусственном интеллекте, со специальным железом, способным обрабатывать считанное число таблиц, хранящих вообще всё, что можно представить.

Сложность не должна пугать? В то время, как люди, разрабатывающие базы данных, стараются максимально упростить языки запросов, некоторые пытаются эту жизнь себе усложнить. Зачем? Что бы писать что-то типа "new ORM_AND('a','b')" параметром в функцию, вместо "a=b" в самом запросе?

Моё отношение вообще к ОРМ. Я изначально исхожу из того, что синтаксис SQL уже максимально подогнан для удобного выбора данных. Максимум, на что я готов пойти, это хранение соответсвий, типа id=user_id, login=user_login, date=user_register_date и т.д., короче, что бы просто использовать короткие имена столбцов, а класс бы уже переводил в реальные и/или подставлял название таблицы, типа table_of_users.user_id='123'. Ну и простейшие CRUD операции. По всем остальным показателям лично составленные SQL запросы выигрывают в читаемости и удобстве разработки.
Ой, да какой там AI - просто приложения, где пользователь сам постоянно определяет всё новые и новые структуры данных, типа как в:
http://dabbledb.com
http://creator.zoho.com

Различные системы управления НСИ и CMS тоже сюда подходят.
Вот именно. Пользователь очень хочет гибко менять структуру объектов и их взаимоотношений.

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

"просто приложения, где пользователь сам постоянно определяет всё новые и новые структуры данных" - таким образом можно описать что угодно, что не всегда отвечает на вопрос "необходимо ли?".

Сделать такую структуру дело не хитрое и такие вещи приходили в голову, уверен, что не менее 99% разработчиков. И этот вопрос лежит не в области ORM, которая может переводить любые данные в любые, хоть из файлов читай. Ведь как абстракция она должна скрывать реализацию от нас, а нам должно быть всё равно с чем она работает. Тут фактически другой подход к организации хранения данных, а ОРМ тут не при чём собственно.
Ну вот тут как раз встал вопрос -- если нам надо максимально просто добавлять и удалять поля и связи в объектах. Какой подход выбрать?

Этот подход решает задачу, но подсознательно мне не нравится. Однако этого мало.
"Ну вот тут как раз встал вопрос -- если нам надо максимально просто добавлять и удалять поля и связи в объектах. Какой подход выбрать?". На этот вопрос не могу так скоро ответить, но я пытался хранить связи в одной таблице, данные в других подобным образом. Мало того, что не наглядно, так ещё и геморрой с составлением запросов. Таблицы огромных размеров и такие запросы занимают очень много времени на обработку. Создание полей, удаление... Как вариант прокатит, конечно, ведь вариантов представления не много: либо по строкам, либо по столбцам. Если последний вариант будет активно использоваться, то лучше поискать какие-то другие БД, построенные именно таким образом. Признаюсь, не задавался вопросом поиска таких, но наверное есть, раз нужда в них уже появилась (да она всегда была в общем-то, только вычислительные мощности не позволяют).

Профсоюз ботов ЖЖ поздравляет Вас с Днем Рождения!
















6597b922eef96b892947c7e64f79a47e
link (при поддержке ru_bots)