Вот задался я таким вопросом,
в java для работы с базой есть интересный фреймворк hibernate и еще один ibatis (те с которыми я сталкивался).
А вот теперь суть вопроса,
если какой либо аналог для PHP чтобы работать
с базой на уровне объектов или же необходимо самому написать свое решение?

Есть. Doctrine, Propel, остальные есть здесь.

Огромное спасибо, буду изучать

А чем не устраивает стандартное средство PHP - PDO?
http://php.net/pdo

Почитай по ссылке Sannis - чем.

и? Нужны низкоуровневые исходники?

Нужно объектное предствление таблиц, т.е. не ОО интерфейс к БД как таковой, а ORM обёртка, насколько я понимаю.

А можно банальный тупой пример, как это выглядит...

Mal Hack, 

http://www.phpdoctrine.org/documentation/m...l/0_11?one-page

Обычная ООП обертка, с большей абстракцией...  Лишнее... ИМХО.

Mal Hack, согласен
Единственное приемущество - более красивый код (эстетическое наслаждение . Приятно, мапишь в XML колонки БД на поля объектов, и просто пользуешь объекты.

Из недостатков выяснилось:
1. Отвратительный перфоманс. Иногда нужно прочитать просто поле объекта, а ORM инициализирует все поля и зависимые сушности, хоторые нах. не нужны в данный момент
2. От ORM ожидаешь что кода будет меньше. Получается наоборот.
3. Усложняется отладка. Вместо понятного отточеного SQL exception получаешь stacktrace ошибок внутри движка ORM
4. Дополнительные уровни абстракции нужны, чтобы скрывать детали реализации, чтобы не приходилось вникать в то, что подложено снизу. На практике хватает дырок в абстракциях, из-за которых пока не разберёшь весь нижний уровень - не поймёшь что сверху происходит. 
5. SQL заменитель (внутренний язак запросов) вместо реального SQL иногда сильно ограничивает возможности

Ну а чего вы хотите? Первая надстройка - переопределенный и расширенный класс PDO или MySQL, вторая - API самой библиотеки...

Это вообще не преимущество. 

Имхо, преимущества ORM заключаются в:

• Увеличение скорость разработки. И это не только за счет генерации готового кода на основании уже спроектированных схем UML, YAML, etc, либо высокого уровня абстракции (хороший пример Zend Framework, где для создания модели объекта, достаточно прописать одно свойство), но и самой работы с этими сущностями.
• Такая технология сильно упрощает создание хорошо масштабируемых систем.
• Расширение функционала адаптера. Хороший пример - это iBATIS. Их шаблонная реализация SQL запросов добавляет еще один уровень абстракции, что дает достаточно интересные перспективы. Представьте prepared statements, которыми можно описать достаточно сложный динамический запрос и с одинаковым синтаксисом для всех БД. Хотя именно к ORM это уже имеет не большое отношение...

Да, это так. Но при грамотном подходе его можно компенсировать.


Если нужно только прочитать поле - то  нужно просто прочитать поле. Зачем использовать ORM там где это не нужно? Для эстетики кода?


Если получаешь stacktrace ошибок движка, то может стоит использовать более удачную реализацию движка, с обработкой ошибок?


То же что и предыдущий пункт.

Mal Hack, а как насчет автоматической генерации админки?
как насчет простого save() вместо написания запросов?
как насчет отсутствия лишнего кода по преобразованию объекта в запрос для записи в базу и кода по преобразованию результатов запроса в объекты при выборке?

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


Против. Абстракция - хорошая вещь, но в меру. Для каждой задачи есть какой-то максимальный уроень абстракции, который нельзя превышать, иначе теряется управляемость скрипта.


Я могу и в массивы преобразовать, что будет куда более оптимальнее. Код-то не лишний, ты просто его не видишь =)