Перейти к содержимому

Фото
- - - - -

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


  • Вы не можете создать новую тему
  • Please log in to reply
40 ответов в этой теме

#31 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 30 Май 2007 - 00:20

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

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

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

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

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

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

  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#32 crazy russian

crazy russian
  • Пользователь
  • 153 сообщений

Отправлено 30 Май 2007 - 10:46

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


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

#33 crazy russian

crazy russian
  • Пользователь
  • 153 сообщений

Отправлено 30 Май 2007 - 11:11

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

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


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

#34 ParadoxL

ParadoxL
  • Постоялец
  • 4 756 сообщений
  • Откуда:Edinburg

Отправлено 30 Май 2007 - 15:27

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

Единственный случай когда оправдано прятать SQL, это когда строишь обьектную модель и в нее инкапсулируешь возможность работы с реляционными базами посредством SQL ... то есть типа INSERT, SELECT, DELETE, UPDATE для обьектов в модели ... это не про ваш случай ... так что я не вижу смысла.
  • 0
Victoria nulla est, Quam quae confessos animo quoque subjugat hostes ...
Верю в смерть после жизни, любовь после секса и в крем после бритья ...

#35 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 30 Май 2007 - 16:36

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

Вот и я о том же

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


  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#36 zedirtybastard

zedirtybastard
  • Пользователь
  • 499 сообщений

Отправлено 30 Май 2007 - 16:53

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

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

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

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

  • 0

#37 Setor

Setor
  • Постоялец
  • 1 890 сообщений
  • Откуда:Эстония, Таллин

Отправлено 31 Май 2007 - 00:31

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

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

(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 проект на нём.
  • 0

#38 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 31 Май 2007 - 00:58

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

А вот теперь (если уж ты знаешь этот факт) попробуй догадаться с трёх раз, почему я так часто "ворчу" в топиках о программировании :D
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#39 ParadoxL

ParadoxL
  • Постоялец
  • 4 756 сообщений
  • Откуда:Edinburg

Отправлено 31 Май 2007 - 04:46

Извините конечно ... но мне кажется это немножко не ORM ... а лиш простой врапер запросов. Никак не больше.
  • 0
Victoria nulla est, Quam quae confessos animo quoque subjugat hostes ...
Верю в смерть после жизни, любовь после секса и в крем после бритья ...

#40 Vladson

Vladson

    XTGamers.com

  • Постоялец
  • 1 921 сообщений
  • Откуда:Эстония, Таллинн

Отправлено 31 Май 2007 - 05:26

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

Мне кажется ты не первый в топике кто это заметил :) (но так топик привлекательнее)
  • 0
Один Владсон может за...ать всех, кроме себя самого. Два Владсона могли бы за...ать абсолютно кого угодно, но Владсон единственный и неповторимый. ©Vladson

Вы либо способны перелопатить тонны информации и отсеять лишнее, либо программистом не будете. ©Psih

Не вазелин, а бизнес-гель ©Avagraen

#41 ParadoxL

ParadoxL
  • Постоялец
  • 4 756 сообщений
  • Откуда:Edinburg

Отправлено 31 Май 2007 - 05:34

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

Сорри ... я не удосужился прочитать весь топик ... читал тока первый пост. <_<
  • 0
Victoria nulla est, Quam quae confessos animo quoque subjugat hostes ...
Верю в смерть после жизни, любовь после секса и в крем после бритья ...