ООП головного мозга

[Gozar]

Наткнулся тут на CodeIgniter и мне это напомнило ООП головного мозга.

public function getData($id = 0, $offset = 0, $limit = 30) {
  $result =  $this->db->select('table1.id, table2.name')
                      ->from('table1')
                      ->join('table2', 'table2.id=table1.id', 'left');
  if ($id) return $result->where('table1.id', (int)$id)->limit(1)->get()->row();
  return $result->limit($limit, $offset)->get()->result();
}

SQL на выходе:

"SELECT table1.id, table2.name
FROM table1
LEFT JOIN table2 ON table2.id = table1.id
LIMIT 10, 30"

ЗАЧЕМ?

Чтобы не учить синтаксис SQL? Неужели он настолько сложный, что нужно делать новый язык и возможно забивать на мощь самого sql ограничивая его собственной реализацией?

Да, я долго обходился простыми запросами, но доучить join-ы и прочую мелочь не составило труда. Стоило прочитать на досуге пару страниц.

Не, я не понимаю.

[Sanda]

Вероятнее, для того, чтобы иметь возможность не задумываться над правильной обёрткой user-defined данных. Чтобы не заморачиваться над тем, как вычесть два месяца из данной даты. Чтобы не строить трёхэтажную конкатеацию строки в зависимости от различных условий, а обходиться более привычными конструкциями. Чтобы иметь один(!!!) синтаксис для обращения к любой реляционной базе данных, будь она MySQL, MSSQL или Oracle.
Ну, то есть это должно быть в правильной реализации подобных вещей. Судя по ->limit, тут только обёртка над MySQL, и тогда подобное нечто теряет глубинный смысл. Лучше реализовать java-like PreparedStatement и на этом успокоиться.
P.S. Если что, я вообще-то большой любитель трёхэтажных запросов с использованием оконных функций, cte и прочей sql-ной радости (: Но подобные обёртки иногда сильно уменьшают количество требуемых проверок в простых запросах.

[Shaci]

причем похоже, что синтаксис SQL все равно надо знать, чтобы составить запрос такой

[Gozar]

Чтобы не заморачиваться над тем, как вычесть два месяца из данной даты.

Это делается с помощью встроенных в sql конструкций. Нет там заморочек.

Чтобы иметь один(!!!) синтаксис для обращения к любой реляционной базе данных, будь она MySQL, MSSQL или Oracle.

Зачем? Эта идея - бредовая. Можно настоящий(реальный) пример, где это помогло в работе? А лучше три таких примера!

Такие реализации только добавляют ненужные тормоза в программу. И в какой-то момент точно не подойдут или не смогут решить ту или иную задачу. В этот момент и возникает вопрос - wat?

[Sanda]

Повторюсь про отсутствие необходимости обёртки пользовательского ввода. Это действительно очень удобно.
Пример из жизни: проект начинался под неким фреймворком, который изначально разрабатывался под Oracle. Под него было сделано N моделей и прочей полезной лабуды. После чего выяснилось, что заказчику очень нужен MSSQL, "потому что одна наша база уже там крутится, вдруг интегрировать будем". Вместо переписывания килотонн кода потребовалось доработать фреймворк, чтобы он кушал чужой синтаксис.
Ещё двух примеров, к сожалению, пока привести не могу (:
По поводу дат - да, действительно, есть встроенные конструкции. С одной проблемой - в каждой БД они свои. Я, как MSSQL-щик, испытываю большие трудности, когда мне приходится общаться с MySQL-ными датами, потому что привык работать с dateadd, datediff и прочим своеобразным синтаксисом.
Разводить холивар не буду. Добавлю только, что любому такому врапперу обязательно нужна функция execQuery - именно для того, чтобы конструкции языка можно было применять в полной мере.
Ещё раз повторюсь, что я сам с удовольствием пишу длинные запросы в виде текста, "потому что так удобнее и быстрее". Но плюсы для начинающих юзеров в таком подходе, несомненно, присутствуют.

[Gozar]

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

Поэтому не убедил.

[Shaci]

Чтобы иметь один(!!!) синтаксис для обращения к любой реляционной базе данных, будь она MySQL, MSSQL или Oracle.

знаю, в RoR используется active record,
http://ru.wikipedia.org/wiki/ActiveRecord

Например
part = new Part()
part.name = "Sample part"
part.price = 123.45
part.save()

создает новую запись в таблице parts с данными значениями
и нам не важно, какая БД у нас используется, Mysql или MongoDB

Что-то в этом есть

[Антон Крамолов]

в этих фреймворках полно нагромождения подобных конструкций, единственное для чего позвалительно написать обертки это для INSERT, UPDATE и DELETE

$db->insert('t', $arr)
$db->update('t', $arr)
$db->delete('t', $id)

[micscr]

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

Поэтому не убедил.

В друпале тысячи строк с запросами. SQL в базах данных отличается.
И чтобы один и тот же код работал с разными БД нужна прослойка.

Раньше в друпале она была процедурная, а сейчас, после pdo, типа такая как ты привел.

Зато можно сайт запустить на какой хочешь базе данных - sqllite, mysql, postgresql, ...

[Tim]

ЗАЧЕМ?

Представь что в зависимости от некоторых условий нужно слегка изменить запрос. Например добавить сортировку или WHERE. Как поступишь со своим лесом из точек и кавычек?

Для простых запросов можно юзать ->query("SLECT ....")
(Это в Zend, в CodeIgniter думаю тоже есть что то подобное)

Хочется ещё более высокого уровня абстракции - ORM к вашим услугам. В Yii мне нравится его использовать. В Zend своего нету, но можно доктрину прикрутить. Про CodeIgniter не знаю.

И чтобы один и тот же код работал с разными БД нужна прослойка.

+1

SQL на выходе:

да, красиво. но мы о PHP. перепиши код на чистый php и посмотрим что получится