ORM на PHP кто делал?

Быстродействие - это такая штука..

Это такая штука что на загруженных сайтах уровень оптимизации до маразма доходит... (вплоть до замены двойных кавычек одинарными)

Если думать о потребляемой приложением памяти, то следует обратить внимание в первую очередь на апаче

На реально нагруженые его даже не ставят

(PS на счёт кавычек приувеличение конечно, но смысл думаю ясен)

Сообщение изменено: Vladson (30 мая 2007 - 00:21 )

Идеальным примером были бы запросы на получение списка продуктов магазина. Например, нужно получить список продуктов из корзины, список продуктов из какого-то заказа, список продуктов с какой-то категории, список продуктов без картинок или с картинками и т.д. По сути, запрос на получение списка продуктов всегда один, но в каждом случае дополнительно могут джойниться разные таблицы и добавляться новые условия, писать по запросу для каждого случая очень утомительно, особенно утомительно вносить в них изменения, вот тут подобный builder был бы очень кстати.

Как насчет view для каждого типа списка + простенький sql builder о котором я писал чуть раньше? Наверняка их не так много и это выйдет дешевле и проще, чем делать generic framework. Если нужен параметризованный view - тогда либо через функции (если база позволяет), либо генерировать его на стороне PHP a la $sql = getProductsFromCatalogue($catalogueId). Это может упростить твой код, сделав большую часть SQL-а общим для всего приложения.

ОРМ на пхп? самолично? уже после этого тему в юмор.
а еще понравились готичные комментарии на албанском %) код тоже так пишете? или только на форуме такие комменты.

По теме: зачем изобретать велосипед? неужели нет нормальных фреймворков для поставленных целей?
а я не могу представить себе систему, которая больше 2х таблиц и 3 селектов, которая потеряла бы что-то от отказа от Хибернейт .
По поводу того, что класс должен сам себя сохранять - я считаю, что тут тогда будет смешение дата слоя и слоя бизнес логики, но все ИМХО.

Что тебя смущает в желании сделать ORM на пхп? Специализированная ORM может состоять из пары классов, заточенная под конкретную таблицу. И она оправдает себя, если избавит программиста выполнять похожие задачи. Как и любая другая технология. Hibernate тоже не панацея, в системах где нужно обновлять/изменять/добавлять много данных или, к примеру, генерировать отчеты, обычный SQL может оказаться эффективнее и удобнее. Любое усложнение системы может привести к тому, что она потом влетит в копеечку. Будь то в необходимости добавлять новые сервера или нанимать/обучать программистов. Помню, в PHP4 (в PHP5 что-нибудь сделали по этому поводу?) была беда, что каждому запросу в памяти выделялся отдельный процесс. В этом случае, дополнительные объекты, созданные громоздким фреймфорком, могут банально повлиять на то количество людей, которые смогут обращаться одновременно к сервису.

По моему вы занимаетесь ерундой и вгоняете всё обратно в каменный век. Разбирать при анализе или исправлении ваши классы сложнее чем простой SQL запрос.

Единственный случай когда оправдано прятать SQL, это когда строишь обьектную модель и в нее инкапсулируешь возможность работы с реляционными базами посредством SQL ... то есть типа INSERT, SELECT, DELETE, UPDATE для обьектов в модели ... это не про ваш случай ... так что я не вижу смысла.

я не вижу смысла.

Вот и я о том же

просто непонимаю зачем это нужно

Спасибо за комментарии, я понял, что зря все эти годы программировал на PHP

С некоторыми комментариями я согласен, с некоторыми - нет. Более подробно далее...

Конечно!
Хочешь МЕГА-быстро (в плане разработки), качественно и надежно - пиши на рельсах
Я до сих пор ф шоке от них.

Сообщение изменено: zedirtybastard (30 мая 2007 - 16:54 )

Это такая штука что на загруженных сайтах уровень оптимизации до маразма доходит... (вплоть до замены двойных кавычек одинарными)

На реально нагруженые его даже не ставят

(PS на счёт кавычек приувеличение конечно, но смысл думаю ясен)

Не спорю, у меня высокий уровень теоретической и практической подготовки в плане оптимизации и секьюритизации приложений на PHP + MySQL. По ходу "службы" приходится сталкиваться с различными работами других людей, в 95% случаев делают туфту. Все мы не идеальны, мало кто делает хорошие приложения, банально мешает лень и нехватка времени. Не знаю что ещё ответить по поводу "зачем изобретать велосипед", "зачем усложнять себе и другим жизнь"... Просто я пришёл к такому выводу, в любом случае я сделаю так, как сочту нужным, просто думал, что есть народ, который использует в повседневной работе какие-то конкретные решения.

Как насчет view для каждого типа списка + простенький sql builder о котором я писал чуть раньше? Наверняка их не так много и это выйдет дешевле и проще, чем делать generic framework. Если нужен параметризованный view - тогда либо через функции (если база позволяет), либо генерировать его на стороне PHP a la $sql = getProductsFromCatalogue($catalogueId). Это может упростить твой код, сделав большую часть SQL-а общим для всего приложения.

Именно так всё и сделано, но идёт повторение кода в SQL запросах, а я уже высказывал своё мнение по данному поводу. Классы моего builder'а занимают с комментариями около 350 строк. Максимум будет 500.

Любое усложнение системы может привести к тому, что она потом влетит в копеечку. Будь то в необходимости добавлять новые сервера или нанимать/обучать программистов. Помню, в PHP4 (в PHP5 что-нибудь сделали по этому поводу?) была беда, что каждому запросу в памяти выделялся отдельный процесс. В этом случае, дополнительные объекты, созданные громоздким фреймфорком, могут банально повлиять на то количество людей, которые смогут обращаться одновременно к сервису.

Мы не говорим про крупные системы, вы слишком всё преувеличиваете Я не рассчитываю, что кто-то будет копать мой код, это уже не мои проблемы, зато лично я повышаю свою производительность на >100% при разработке нового проекта.

Насчёт запросов и выделения памяти - это Apache выделяет процесс на каждый запрос. Насчёт громоздкости - посмотри на Zend Framework, Symfony - тебе такие тормоза даже не снились в самом страшном кошмаре! Тот же битрикс кмс. И ничего, ставят, всё работает отлично. Там огромная роль уделяется кешированию, кешируется всё что только можно, в симфонии даже содержимое частоиспользуемых классов кладётся в 1 здоровый файл... Но проблема производительности - это забота сисадминов, я могу написать десятки вещей, которые повысят производительность в целом в несколько раз, если имеется свой сервер!

По моему вы занимаетесь ерундой и вгоняете всё обратно в каменный век. Разбирать при анализе или исправлении ваши классы сложнее чем простой SQL запрос.

Согласен со вторым предложением, но запросы составлять мне Мало кто лезет в самопал, в большинстве случаев говорят, что надо писать с нуля, а если лезть в мои объекты, то мало не покажется, но у меня есть человек - новичок в ПХП, я ему всё разложил по полочкам, и он уже хорошо понимает как всё работает, а на самом деле всё ведь просто - правильный ООП облегчает жизнь разработчику. Мне не раз приходилось лезть в известные ОпенСорс решения и я был поражён как всё написано, о мастштабировании не могло быть и речи, всё настолько завязано друг на друге, ХТМЛ смешан с ПХП, куча функций с глобальными переменными - ужас. А когда смотришь на "простой" запрос типа "SELECT ".(($rows <>'')? $rows:"*")." FROM ".$table." ".(($query <>'')? "WHERE ".$query:"")." ".(($defLimit <>'')? "LIMIT ".$defLimit.",".$perPage."":"")." " влосы дыбом встают, проще уж 1 раз разобраться с билдером, чем ломать голову глядя на подобные вещи. Всё полностью зависит от реализации, я стремлюсь только к простоте, я ведь не буду усложнять себе жизнь, я прекрасно вижу плюсы и минусы от использования подобных вещей.

Конечно!
Хочешь МЕГА-быстро (в плане разработки), качественно и надежно - пиши на рельсах
Я до сих пор ф шоке от них.

Я смотрел демки различных фреймворков, некоторые пробывал сам (все на ПХП) - да, удобно, поражает скорость с которой можно создавать новые проекты, но опять таки чтобы выйти на 100% выхлоп нужно знать систему как свои 5 пальцев. Руби штука интересная, но я даже никогда её не видел и не знаю есть у нас в Эстонии хоть 1 проект на нём.

приходится сталкиваться с различными работами других людей, в 95% случаев делают туфту.

А вот теперь (если уж ты знаешь этот факт) попробуй догадаться с трёх раз, почему я так часто "ворчу" в топиках о программировании

Извините конечно ... но мне кажется это немножко не ORM ... а лиш простой врапер запросов. Никак не больше.

но мне кажется это немножко не ORM

Мне кажется ты не первый в топике кто это заметил (но так топик привлекательнее)

Мне кажется ты не первый в топике кто это заметил (но так топик привлекательнее)

Сорри ... я не удосужился прочитать весь топик ... читал тока первый пост.