Какие запросы мешают вам использовать ORM?

[Sad Spirit]

Хватит вертеться как уж на сковородке:

ORM не призван облегчить работу с данными. ...
В качестве механизма продления жизни может быть выбрано все что угодно от Serialize и XML, до РСУБД.

ORM расшифровывается как Object-Relational Mapping, то есть "построение отображения отношение <=> объект". Сказки про Serialize и XML поэтому можешь засунуть поглубже.

Поэтому мы пытаемся говорить о СУБД, а ты пытаешься зачем-то отмазываться.

 

[Mich]

whirlwind, гыгы, ты считаешь это

$banner = new Banner(); 
$banner->setLimit(20); 
$banner->filterBy("banner_types_id",6); 
$banner->filterBy("lang","eng"); 
$banner->filterBy("show",true); 
$banner->filterCustom("((NOT except1 AND '%' LIKE url) OR (except1 AND '%' NOT LIKE url))");

все что угодно от Serialize и XML

Все-таки надо как-то теорию к практики привязывать

 

[bkonst]

Автор оригинала: whirlwind
bkonst не надо лепить монстра. Не заставляйте делать ORM все что не хотите делать сами. Заставляйте его выполнять рутинную работу. Тогда и синтаксис будет нормальным.

По моему, сложность синтаксиса слабо зависит от "монструозности" ORM. Просто или мы строим описание запроса(*) с помощью некоего API, либо записываем его на компактном языке, приближенном к человеческому - SQL. Первый вариант более громоздок, но легче автоматизируется; второй вариант красив и компактен, но требует процедур разбора и хорошей обработки ошибок. Лично мне нравится первый подход - незачем изобретать еще один SQL.

Sad Spirit

По теме: по-моему попытки построить отображение отношение <=> объект достаточно глупы, пока для ООП у нас вместо математической теории наподобие реляционной алгебры только танцы с бубнами --- "рефакторинг", "паттерны" и т.п.

Алгоритм построения отображения есть. Любой, кому не лень, реализует CRUD.

И не надо, пожалуйста, сравнивать ООП и реляционную алгебру. Они соотносятся примерно так же, как функциональное программирование и Windows API.

А что мешает написать триггеры before и after? Дополнительным плюсом будет то очевидное обстоятельство, что залезший грязными руками в базу человек не сможет грубо и цинично надругаться над беззащитной бызыныс логикой, что он сможет проделать в случае использования волшебного ORM.

Залезший грязными руками в базу человек может и триггеры удалить, и вообще DROP TABLE сделать. Триггеры тут не панацея. А уж запихивание бизнес-логики в базу попахивает использованием инструмента не по назначению.

О чём "разном"? Я тебе пишу, что гениальная "смена алиасов" спокойно реализуется на уровне базы представлениями, совершенно необзяательно что-то ещё городить, а потом хвалиться новой добавленной функциональностью.

Мы будем на каждый запрос пользователя CREATE VIEW / DROP VIEW делать? Область использования CREATE VIEW такая же, как статического SQL запроса, намертво зашитого в PHP-код.

atv

Посмотрите примеры которые вы приводите, чем они абстрактнее SQL, только JOIN-ами и ключами.

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

(*) почему всё сводится к запросам? Потому что набор простых операций CRUD и собственно отображение O на R и обратно проблем не вызывают.

 

[Mich]

Залезший грязными руками в базу человек может и триггеры удалить, и вообще DROP TABLE сделать. Триггеры тут не панацея. А уж запихивание бизнес-логики в базу попахивает использованием инструмента не по назначению.

Вот раскопал ссылку - http://xpoint.ru/forums/internet/theory/thread/35663.xhtml#332575

 

[whirlwind]

>Сказки про Serialize и XML поэтому можешь засунуть поглубже.

По моему ты все еще не врубаешься. В аббревиатуре на первом месте Object. Ты пытаешься доказать что

Открыта вакансия PR менеджера. Знание SQL обязательно.

это абсолютно нормально


Mich - это как раз зависимость от специфики источника. Чем таких зависимостей меньше, тем выше переносимость. ORM уменьшает количество таких зависимостей.

 

[Sad Spirit]

Автор оригинала: bkonst
Алгоритм построения отображения есть. Любой, кому не лень, реализует CRUD.

Дык, логично, сам использую нечто типа Row Data Gateway. Но это отображение кортеж <=> ассоциативный массив получается.

И не надо, пожалуйста, сравнивать ООП и реляционную алгебру. Они соотносятся примерно так же, как функциональное программирование и Windows API.

Именно.

Залезший грязными руками в базу человек может и триггеры удалить, и вообще DROP TABLE сделать. Триггеры тут не панацея. А уж запихивание бизнес-логики в базу попахивает использованием инструмента не по назначению.

У залезшего с логином веб-пользователя не будет прав на удаление триггеров и таблиц. А вот права на вставку / удаление / изменение записей будут... А проверки все остались в прокладке...

Мы будем на каждый запрос пользователя CREATE VIEW / DROP VIEW делать? Область использования CREATE VIEW такая же, как статического SQL запроса, намертво зашитого в PHP-код.

Не будем, конечно. А alias'ы продемонстрированные нашим штатным демагогом мы что, на каждый запрос менять собираемся?

 

[bkonst]

Mich
Угу. Там же и контраргументы.
Результат такого подхода, как минимум - сильная привязка к конкретной СУБД.

 

[Sad Spirit]

Автор оригинала: whirlwind
>Сказки про Serialize и XML поэтому можешь засунуть поглубже.

По моему ты все еще не врубаешься. В аббревиатуре на первом месте Object. Ты пытаешься доказать что

Открыта вакансия PR менеджера. Знание SQL обязательно.

это абсолютно нормально

Волшебно. Ни одного ответа по существу.

 

[whirlwind]

Sad Spirit

>А alias'ы продемонстрированные нашим штатным демагогом мы что, на каждый запрос менять

Самое интересно, чт нам никто не мешает это сделать. И это никак не отразится на быстродействии, которое длятебя так важно. + ко всему этому программеру не нужно быть продвинутым базистом, что бы писать триггеры, создавать вьюхи и т.п. Т.е. все решается в рамках языка. Думаю это очень весомый фактор для ленивых программистов.

 

[Sad Spirit]

Автор оригинала: bkonst
Результат такого подхода, как минимум - сильная привязка к конкретной СУБД.

Сильная привязка к конкретной реализации ORM --- это, конечно же, огромный шаг вперёд.

 

[whirlwind]

ЗЫ. Sad Spirit по моему это уже нифига не смешно. Ты что, сомневаешься что в качестве датасорса можно использовать результаты Serialize? Дружище, да ты походу теоретик чистой воды. Могу тебя обрадовать - прекрасно кешируются объекты с блобами, например картинки. Используется для того, что бы избежать лишних подключений к БД. Мда, хотел бы я посмотреть сколько кода и самое главное какого ты написал с 2к года. В общем я твою позицию понял.

 

[bkonst]

Автор оригинала: Sad Spirit
Дык, логично, сам использую нечто типа Row Data Gateway. Но это отображение кортеж <=> ассоциативный массив получается.

Именно. А что-такое объект, по вашему? Не ассоциативный массив с привязанными к нему методами?

У залезшего с логином веб-пользователя не будет прав на удаление триггеров и таблиц. А вот права на вставку / удаление / изменение записей будут... А проверки все остались в прокладке...

И откуда у веб-пользователя логин/пароль к базе? И почему тогда этот злобный веб-пользователь не может случайно найти логин/пароль админа?

Не будем, конечно. А alias'ы продемонстрированные нашим штатным демагогом мы что, на каждый запрос менять собираемся?

Это его личный неудачный пример.

 

[whirlwind]

Mich по поводу XML в качестве DS. Т.к. методы итератора делегируют объекту этого самого итератора, а конкретный DAO знает о функционале драйвера БД, в случае вызова filterCustom для двайвера XML будет возбуждаться исключение, которое позволит быстро локализовать это самое нарушение. Я думаю гораздо удобнее подправить несколько строк, чем переписать все нафик с нуля

 

[Sad Spirit]

Автор оригинала: whirlwind
ЗЫ. Sad Spirit по моему это уже нифига не смешно. Ты что, сомневаешься что в качестве датасорса можно использовать результаты Serialize?

По-моему тебя чуть выше уже ткнули мордой в налитый на пол Datasource?

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

А вот и личные наезды пошли.

Слив защитан, дружок.

-~{}~ 25.09.06 14:46:

Автор оригинала: bkonst
И откуда у веб-пользователя логин/пароль к базе?

Из веб-приложения. В коде он там прописан обычно...

И почему тогда этот злобный веб-пользователь не может случайно найти логин/пароль админа?

Потому что он в коде не прописан, очевидно.

 

[whirlwind]

> Это его личный неудачный пример.

Почему неудачный. Если вы с этим не сталкивались, это еще не значит, что такой ситуации не возникнет. Последнее что помню из подобных задач, это надо было fake-магазин настроить для работы с двумя категориями клиентов. Что то вроде на показуху и на реальные заказы. Сам магаз писал другой программер на другом языке. Была база в которую с его магаза писались ордера. На мне был джойн, который по условию определял категорию клиента. Нормальные заказы нужно было писать в одну базу, а все прочие в другую. Во первых очень помогло когда для объекта указывается DSN. Во вторых, ненавижу таблицы в которых имена колонок префиксуются именем таблицы. С помощью aliases обернул неугодную таблицу. С помощью DSN настроил источник данных. Объект был один. Телодвижений 0.5%. Таких примеров, где ORM рулит в плане экономии времени, у меня куча и маленькая тележка.

 

[bkonst]

Автор оригинала: Sad Spirit
Сильная привязка к конкретной реализации ORM --- это, конечно же, огромный шаг вперёд.

Представь себе. Мы еще и к языку привязываемся (PHP), к его стандартным функциям, и к используемому шаблонизатору. Только вот при смене одной библиотеки на другую со схожей функциональностью можно быстро на коленке написать обертку, а смена СУБД приведет к тому, что все любовно написанные триггеры и хранимые процедуры придется выбросить.

-~{}~ 25.09.06 14:54:

Sad spirit

Из веб-приложения. В коде он там прописан обычно...

И как веб-пользователь увидит код Web-приложения? (Приступ острого кретинизма у администратора не считаем, так как в этом случае администраторский доступ уйдет с той же легкостью).

whirlwind

Почему неудачный. Если вы с этим не сталкивались, это еще не значит, что такой ситуации не возникнет.

Ситуация возникнет, но может быть легко разрулена штатными средствами.

 

[Mich]

Я думаю гораздо удобнее подправить несколько строк, чем переписать все нафик с нуля

Я все-таки считаю что это неактуально. Не могу себе представить ситуацию, когда было бы необходимо сменить СУБД на XML, Serialize. А чтобы оно еще при этом и заработало... =)

Любопытно было бы посмотреть на библиотеку, реализующую такой функционал http://phpclub.ru/talk/showthread.php?postid=653312#post653312 Это возможно?

 

[whirlwind]

>Любопытно было бы посмотреть на библиотеку, реализующую такой функционал http://phpclub.ru/talk/showthread.php?postid=653312#post653312 Это возможно?

http://prolib.ru/.closed/wcmf.zip

Только пинать не надо - это не релиз. Если есть желание, можете помочь в разработке. Если бы оно было готово для публичного юзания, давно бы выложил в SVN.

ЗЫ. вот, что бы сгладить впечатление от бардака во фреймворке, реальный проектик в качестве примера. делал для товарища портфолио + статические документы. писалось за час левой ногой. по моему выглядит неплохо.

http://prolib.ru/.closed/billkn.zip

 

[Mich]

Спасибо, буду разбираться.

 

[mrjazz]

Автор оригинала: john.brown
Так, полагаю, все и рады были бы Но суровая действительность такова, что объектные бд пока имеет мизерную распространенность, и жить приходится с тем, что есть... А есть траблы со связкой реляционной бд с объектной моделью - вот и пытаются решить их, кто как может.
Чисто мое имхо, что орм все же есть заплатка на несоответствие хранимых данных их представлению в ооп приложении, и, как таковое, имеет массу недостатков... Но, зато, решает более менее стандартизовано перевод данных в объекты. Что, несомненно, плюс...

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