История изменений

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

Ну, по моему ты позволяешь себе игнорировать аргументы.

1) Лаконичность. В последнем моём варианте строк 13 (вместе с определением и вызовом, если я верно подсчитал), в твоём - 12. В чём мазохизм? В передаче функций как параметров? Ну пхп есть пхп, что тут сделаешь. Вряд ли это можно считать серьёзным аргументом против ОРМ. Форматировать я буду по-другому, но это дело вкуса во многом.

При этом если нужно сделать примерно тот же запрос в двух разных местах, у тебя будет 24 строки кода, а у меня 16, для трёх (что тоже случается) ты пишешь 36, я 19.

2) Простота поддержки. Вот опять же, ты забыл стрип тегс. Это правда лажа, если только ты делаешь не для одного единственного человека систему (или ты стрипаешь при выводе). В твоём случае тебе нужно будет пройти по всем местам где ты делаешь запросы, а их может быть заметно больше двух. В моём - лишь одно место, файл. При этом все эти файлы лежат в одном месте, т.е. если я вспомню про стрип_тегс позднее, то мне будет сильно проще чем тебе. При этом меньше тестировать и отлаживать — когда ты пишешь в стиле php3, то ты там делаешь тучу всего где можно налажать, для примера: не так сопоставить параметры (на место contract_owner_code поставить description и наоборот, ошибиться в написании зарпоса). Таких ошибок невозможно сделать с использованием ORM.

Если массив не указан - будет выполняться более лёгкая \pg_query со строкой вида «insert into a (id) values (» . $id . ")"; Потому что я точно знаю, что это $id я уже точно обернул в (int) или intval() и никаких дополнительных преобразований Postgres делать не должен.

В целом, аргумент про «я уже обернул и теперь вставил в строку руками» мне кажется наивным по сравнению с $obj->value = $a;. Как бы просто разный уровень автоматизации (типа если бы ассемблерщик говорил сишнику «а я всегда могу поместить в ax». Ну можешь, но толку?) Поэтому я его не рассматриваю, кроме как как сознательную оптимизацию. Но при сознательной оптимизации ты можешь всегда написать такой запрос, какой нужно, без орм. Поэтому аргумент не имеет смысла на мой взгляд.

Примерно то же относится к новым фичам БД, вариантов несколько:
-- просто не трогать, если всё работает
-- написать запрос руками, если очень важно
-- добавить функциональность в ОРМ, использвать ОРМ
-- подождать пока добавят функциональность в ОРМ и использовать ОРМ

Т.е. этот вопрос в целом, тоже смысла не имеет: варианты ровно те же, что и с ОРМ + можно подождать пока сделают другие.

ОРМ он для производительности труда, и при написании и при поддержке. Обычно это не 100% функционала БД, обычно что то вроде «большинство часто используемых». Потому как гораздо проще написать

  $res = ORM::factory('RentDate', @$_POST['rent_id'])
  ->values($_POST)
  ->save()
  ->as_array();
//  print_r($res);
//  ['rend_id' => 25, 'contract_number' => ...]

Это ORM делает? Или считается, что PHP-программисту об этом думать не надо?

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

3) ну и в примере, что надо менять если скажем добавим в таблицу новое свойство?

Код вставки/обновления остаётся такой же

ORM::factory('RentDate', @$_POST['rent_id'])
  ->values($_POST)
  ->save();

$o = ORM::factory('RentDate', @$_POST['rent_id'])
$o->values($_POST, [...])

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

Ну, по моему ты позволяешь себе игнорировать аргументы.

1) Лаконичность. В последнем моём варианте строк 13 (вместе с определением и вызовом, если я верно подсчитал), в твоём - 12. В чём мазохизм? В передаче функций как параметров? Ну пхп есть пхп, что тут сделаешь. Вряд ли это можно считать серьёзным аргументом против ОРМ. Форматировать я буду по-другому, но это дело вкуса во многом.

При этом если нужно сделать примерно тот же запрос в двух разных местах, у тебя будет 24 строки кода, а у меня 16, для трёх (что тоже случается) ты пишешь 36, я 19.

2) Простота поддержки. Вот опять же, ты забыл стрип тегс. Это правда лажа, если только ты делаешь не для одного единственного человека систему (или ты стрипаешь при выводе). В твоём случае тебе нужно будет пройти по всем местам где ты делаешь запросы, а их может быть заметно больше двух. В моём - лишь одно место, файл. При этом все эти файлы лежат в одном месте, т.е. если я вспомню про стрип_тегс позднее, то мне будет сильно проще чем тебе. При этом меньше тестировать и отлаживать — когда ты пишешь в стиле php3, то ты там делаешь тучу всего где можно налажать, для примера: не так сопоставить параметры (на место contract_owner_code поставить description и наоборот, ошибиться в написании зарпоса). Таких ошибок невозможно сделать с использованием ORM.

Если массив не указан - будет выполняться более лёгкая \pg_query со строкой вида «insert into a (id) values (» . $id . ")"; Потому что я точно знаю, что это $id я уже точно обернул в (int) или intval() и никаких дополнительных преобразований Postgres делать не должен.

В целом, аргумент про «я уже обернул и теперь вставил в строку руками» мне кажется наивным по сравнению с $obj->value = $a;. Как бы просто разный уровень автоматизации (типа если бы ассемблерщик говорил сишнику «а я всегда могу поместить в ax». Ну можешь, но толку?) Поэтому я его не рассматриваю, кроме как как сознательную оптимизацию. Но при сознательной оптимизации ты можешь всегда написать такой запрос, какой нужно, без орм. Поэтому аргумент не имеет смысла на мой взгляд.

Примерно то же относится к новым фичам БД, вариантов несколько:
-- просто не трогать, если всё работает
-- написать запрос руками, если очень важно
-- добавить функциональность в ОРМ, использвать ОРМ
-- подождать пока добавят функциональность в ОРМ и использовать ОРМ

Т.е. этот вопрос в целом, тоже смысла не имеет: варианты ровно те же, что и с ОРМ + можно подождать пока сделают другие.

ОРМ он для производительности труда, и при написании и при поддержке. Обычно это не 100% функционала БД, обычно что то вроде «большинство часто используемых». Потому как гораздо проще написать

  $res = ORM::factory('RentDate', @$_POST['rent_id'])
  ->values($_POST)
  ->save()
  ->as_array();
//  print_r($res);
//  ['rend_id' => 25, 'contract_number' => ...]

Это ORM делает? Или считается, что PHP-программисту об этом думать не надо?

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

3) ну и в примере, что надо менять если скажем добавим в таблицу новое свойство?

Код вставки/обновления остаётся такой же

ORM::factory('RentDate', @$_POST['rent_id'])
  ->values($_POST)
  ->save();

$o = ORM::factory('RentDate', @$_POST['rent_id'])
$o->values($_POST, [...])

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

Ну, по моему ты позволяешь себе игнорировать аргументы.

1) Лаконичность. В последнем моём варианте строк 13 (вместе с определением и вызовом, если я верно подсчитал), в твоём - 12. В чём мазохизм? В передаче функций как параметров? Ну пхп есть пхп, что тут сделаешь. Вряд ли это можно считать серьёзным аргументом против ОРМ. Форматировать я буду по-другому, но это дело вкуса во многом.

При этом если нужно сделать примерно тот же запрос в двух разных местах, у тебя будет 24 строки кода, а у меня 16, для трёх (что тоже случается) ты пишешь 36, я 19.

2) Простота поддержки. Вот опять же, ты забыл стрип тегс. Это правда лажа, если только ты делаешь не для одного единственного человека систему (или ты стрипаешь при выводе). В твоём случае тебе нужно будет пройти по всем местам где ты делаешь запросы, а их может быть заметно больше двух. В моём - лишь одно место, файл. При этом все эти файлы лежат в одном месте, т.е. если я вспомню про стрип_тегс позднее, то мне будет сильно проще чем тебе. При этом меньше тестировать и отлаживать — когда ты пишешь в стиле php3, то ты там делаешь тучу всего где можно налажать, для примера: не так сопоставить параметры (на место contract_owner_code поставить description и наоборот, ошибиться в написании зарпоса). Таких ошибок невозможно сделать с использованием ORM.

Если массив не указан - будет выполняться более лёгкая \pg_query со строкой вида «insert into a (id) values (» . $id . ")"; Потому что я точно знаю, что это $id я уже точно обернул в (int) или intval() и никаких дополнительных преобразований Postgres делать не должен.

В целом, аргумент про «я уже обернул и теперь вставил в строку руками» мне кажется наивным по сравнению с $obj->value = $a;. Как бы просто разный уровень автоматизации (типа если бы ассемблерщик говорил сишнику «а я всегда могу поместить в ax». Ну можешь, но толку? Поэтому я его не рассматриваю, кроме как как сознательную оптимизацию. Но при сознательной оптимизации ты можешь всегда написать такой запрос, какой нужно, без орм. Поэтому аргумент не имеет смысла на мой взгляд.

Примерно то же относится к новым фичам БД, вариантов несколько:
-- просто не трогать, если всё работает
-- написать запрос руками, если очень важно
-- добавить функциональность в ОРМ, использвать ОРМ
-- подождать пока добавят функциональность в ОРМ и использовать ОРМ

Т.е. этот вопрос в целом, тоже смысла не имеет: варианты ровно те же, что и с ОРМ + можно подождать пока сделают другие.

ОРМ он для производительности труда, и при написании и при поддержке. Обычно это не 100% функционала БД, обычно что то вроде «большинство часто используемых». Потому как гораздо проще написать

  $res = ORM::factory('RentDate', @$_POST['rent_id'])
  ->values($_POST)
  ->save()
  ->as_array();
//  print_r($res);
//  ['rend_id' => 25, 'contract_number' => ...]

Это ORM делает? Или считается, что PHP-программисту об этом думать не надо?

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

3) ну и в примере, что надо менять если скажем добавим в таблицу новое свойство?

Код вставки/обновления остаётся такой же

ORM::factory('RentDate', @$_POST['rent_id'])
  ->values($_POST)
  ->save();

$o = ORM::factory('RentDate', @$_POST['rent_id'])
$o->values($_POST, [...])