Javascript-форум (https://javascript.ru/forum/)
-   Серверные языки и технологии (https://javascript.ru/forum/server/)
-   -   ООП головного мозга (https://javascript.ru/forum/server/34095-oop-golovnogo-mozga.html)

Gozar 20.12.2012 11:30

ООП головного мозга
 
Наткнулся тут на 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 20.12.2012 11:52

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

Shaci 20.12.2012 12:09

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

Gozar 20.12.2012 13:26

Цитата:

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

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

Цитата:

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

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

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

Sanda 20.12.2012 14:02

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

Gozar 20.12.2012 15:39

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

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

Shaci 20.12.2012 16:08

Цитата:

Чтобы иметь один(!!!) синтаксис для обращения к любой реляционной базе данных, будь она 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

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

Антон Крамолов 20.12.2012 17:12

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

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

micscr 20.12.2012 20:07

Цитата:

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

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

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

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

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

Tim 20.12.2012 23:45

Цитата:

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

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

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

Цитата:

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

Цитата:

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


Часовой пояс GMT +3, время: 23:37.