Привет всем.
Подскажите начинающему программисту, а зачем нужны ORM'ы в виде Doctrine и ему подобные?
Ведь куча всякого кода, зачем...

Если можно в одной странице прописать
<?php

$r=mysql_query("SELECT * FROM dummy WHERE bar = 'baz'");
$a = mysql_fetch_assoc($r)
require "header.php";

в header.php файле принять переменную

<p> Здесь: <?php echo $a['foo']; > </p>

Зачем городить огороды с ORM'ами?

ИзопропилNekZ$r=mysql_query("SELECT * FROM dummy WHERE bar = 'baz'");
параметры и PDO - не осилил? тогда только ORM спасёт
А что это? Мой вариант работает безо всяких сложностей!

-k2-,

Пффф... JOIN в помощь мне

skyANA,

Логично. Зачем мне в шаблонизаторе PHP ООП?

ScareCrow,

Ой... И правда. А я ещё nginx конфиг не скинул, чтобы скрипт вообще работал. И DDL для таблицы. Shame on me.

alex564657498765453,

Многобукаф, ниасилил.
Единственное, что бросилось в глаза:

alex564657498765453Я: - фуфло ваши ORM

alex564657498765453я не говорю что ОРМ плохо.


Помню на предыдущей работе, когда я работал в вебдев-компании, у операторов PHP программистов PHP был вступительный экзамен "Напиши ORM за 6 часов". Потом подняли планочку "напиши ORM за 4 часа". Видимо, это уже менталитет велосипедостроительный...

alex564657498765453,

Прочитал твой поток сознания пост. Что бы хотелось заметить -- ты мыслишь больно узко, смотря только на связку PHP/MySQL и всего, что отсюда вытекает, поэтому и выводы делаешь соответствующие. Вопрос стоял шире -- зачем-нужен-ORM?
Если мы обратимся к DDD подходу, тут рассматривается построение модели предметной области и вся бизнес-логика будет заложена именно в клиентском коде (толстом клиенте), т.е. не в базе данных, на триггерах, хранимых процедурах, представлениях и прочем. Подход с перекладыванием бизнес-логики в БД, привязывает вашу программу к именно этой базе. А что если сойдутся звёзды, и, тебе придётся переходить на PostgreSQL, то все ваши хранимочки придётся переписывать на другой встроенный язык БД? No way!
Перекладывание вычислительной мощности на клиентский код решает множество проблем, в т.ч. и распределение нагрузки.
Отслеживание онлайна юзеров -- почему бы не использовать memcache/redis для этого и хранить все ID пользователей в быстрой памяти.
На базе сферического в вакууме ORM'а можно построить неплохую модель предметной области, полностью абстрагируясь от используемой системы хранения данных, будь она в памяти, на диске, а может быть сразу на разных серверах и в памяти клиентского кода одновременно, со всеми кэшами, триггерами/коллбэками и прочим

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

Ну вдруг твой начальник-гомофоб прочитал, что выбор MySQL больше используется в конторах с разработчиками-содомитами. Он сразу же скажет тебе "Удаляй мускул, ставь PostgreSQL/MSSQL/SQLite/etc.". А ты такой "не могу...".

alex564657498765453и как верно подметил, если взглянуть в расшифровку ОРМ, так вот от этой функции я бы не отказывался... работать не с масивом или обьектом который стд-класс, а по конкретней.

Что по-конкретней?

alex564657498765453я противник именно того что всё тащат в этот орм. вот это зачем???

Что тащат? Кучу зависимостей от сторонних либ, или что? Или оверхеда много и перфоманс проседает?

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

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

Зачем вообще хранить в базе такое легко вычислимое поле? Что куролесить ты собрался?

alex564657498765453другой пример, логирование изменений каких либо...например история пополнений щёта.

Это пример чего? Там где нельзя использовать ОРМ, или что?

alex564657498765453третий, зачем орм проверяет уникальность емейла нового юзера, вместо вставки записи и в случае ошибки анализировать её(что ты там говорил про разгрузить базу???)

Ха, а тут уже всё зависит от твоего ОРМа. Если ты правильно в нём опишешь существующую модель, то он сам будет перехватывать ошибку нарушения уникальности поля, учитывая, что современные ОРМы расширяемые, как на уровне бэкэндов к конкретным базам, так и на общем уровне логики.

alex564657498765453пятый - скажем у меня есть юзер, и ему мой вебсервис выделяет ресурс - айди юзера ставиться значением внешнего ключа в таблицу ресурсы одной из записей. и логика такова, что если юзеру даёться новый ресурс, то старый автоматически освобождаеться (внешний ключ - нулл) - ресурсы, номера дозвона через интернет(факсы например без факсового аппарата и телефоной линии).
вот почему бы базе не делать это автоматически, зачем чтобы ОРМ сделал тоже самое.

Костылями пахнет.

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

Именно! Абстрагируемся. Мы, программисты, стараемся всё абстрагировать по слоям, стараясь сузить обязанности каждого программного слоя.
Насчёт особенностей, читай выше, как ты расширишь свой бэкэнд работы с БД, так и будет.

alex564657498765453а если ваш орм может работь с джейсонб данными, то закаким можно будет перейти на мускл который в помине незнает что это такое??? может тогда орм должен досоздать табилцы у мускла, дабы имитировать поддержку джейсонб с индексацией???

Насчёт мускуля не могу ничего, но Postgres уже научился это делать (повод перейти на него?).

alex564657498765453ну тоесть как можно переходить на другую субд ,если мы вообще кроме анси скл не используем больше ничего. ради чего?? ради производительности?

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

оракал умеет с деревьями работать, ну напишите ОРМ абстрагировавшись от этого факта.
некоторые субд умеют пронумеровать записи, мы тоже абстрагируемся в наших ОРМ от этого.

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

Опять смотрим наверх. Все СУБД-специфичные вещи можно вынести в бэкэнд ОРМа, работающий именно с этой СУБД. А уж как он внутри это всё реализует (сам клиентскими мощностями делает это, либо же перекладывает ответственность на СУБД, либо говорит "Sorry, I can't do that, my lord"), нас сверху не должно волновать. Триггеры можно заменить на эвенты, например .