LINUX.ORG.RU

Пыхотред

 


1

5

А чего это у нас, в нашем загончике, нет закрепленного пыхотреда?

Вот теперь есть(надеюсь, его закрепят).

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

В тред приглашаются все пыхобоги, пыходемоны, пыхофрилансеры, простые пыхари, и даже пыхоненавистники.

Обсудить есть много чего, начиная с различий версий, особенностей языка, CMS-ок, фреймворков, и заканчивая говнокодом.

<?php

Ответ на: комментарий от erfea

Ты прекрасно понимаешь, что UID на самом деле строковые данные, а когда речь идет о бинарных обычно имеют ввиду всякие pdf, zip и так далее, впихнутые в БД.

Цифры 37 и 16 сравнить можешь? Где раздувание, где замедление?

Сколько миллионов UUID ты хранишь, что решил экономить этот 21 байт?

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

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

Suntechnic ★★★★★ ()
Ответ на: комментарий от no-such-file

А тебе кто сказал, что бинарные данные это непременно blob.mkv?

Почти всегда когда я с этим сталкиваюсь это blob.mkv. В лучшем случае какой-нибудь doc.

Это могут быть например ключи шифрования или сами шифрованные данные.

Но зачем? Выше уже был пример с UUID. Если это UUID и по нему нужно делать выборку, это еще можно понять. Для чего шифрованные данные в БД? Храни их тупо в файлах или NoSQL.

Какие запросы вы строите по своим бинарным данным интересно?

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

Ты прекрасно понимаешь, что UID на самом деле строковые данные, а когда речь идет о бинарных обычно имеют ввиду всякие pdf, zip и так далее, впихнутые в БД.

Ты конченный, иди лечись.

erfea ★★★★★ ()
Ответ на: комментарий от Suntechnic

Для чего шифрованные данные в БД? Храни их тупо в файлах или NoSQL.

Выборка мне нужна не по бинарным данным, но мне нужны бинарные данные по выборке. Ты мне предлагаешь специально для бинарных данных завести отдельный NoSQL и делать сначала запрос в SQL а потом ещё по id в NoSQL? Совсем поехавший?

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

Да он клиннический идиот, не обращайте внимание.

ЗЫ а у меня выборка по UUID имеет место быть. Надо его видимо в тексте хранить в NoSQL, чтобы базу не рпздувать )))

erfea ★★★★★ ()
Ответ на: комментарий от templarrr

Я сам не стал глубоко копать, но он возможно выполнять это дело начинает. У меня нет времени на это. Рандом какой-то. Лечится как и говорил функцией HEX() со стороны мускула, т.е. устраняем обмен в биннарном виде и код работает.

erfea ★★★★★ ()
Ответ на: комментарий от erfea

ЗЫ а у меня выборка по UUID имеет место быть.

Странно, что ты не можешь ответить на вопрос templarrr в таком случае, ведь ты утверждал, что хранишь UUID в бинарном виде, и выборка у тебя по нему есть... Похоже ты заврался.

Надо его видимо в тексте хранить в NoSQL

Я такого нигде не говорил - я напротив - согласился что UUID логично хранить в БД, но не вижу причин хранить его там в бинарном виде.

Suntechnic ★★★★★ ()
Ответ на: комментарий от anonymous

Ты невежа, до ужаса. Даже в БД типы данных Binary\Varbinary\Blob - это разные типы данных.

Ага - чар, варчар и текст, от чего как раз у erfea и попоболь - он то думает, что они и правда бинарные. Я в курсе. А единственно по настоящему бинарный тип как раз и есть BOOLEAN.

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

Наоборот же, все данные бинарные, нюансы в интерпретации. Определяя тип ты подсказываешь СУБД как эффективно эти данные хранить и как их обрабатывать. Строка подразумевает приведение к некой кодировке, бинарь надо тупо получать и отдавать как есть (на чем пхп спотыкается как раз). А разницы что хранить: 10 мегов текста или бинаря, нету никакой. Можно и в файлах держать блобы, но прикол в том, что база тоже хранит все в файлах, никакой магии там нет. И ей наверно виднее как оптимально это все писать/читать, иначе бы просто не было типа BLOB.

anonymous ()
Ответ на: комментарий от anonymous

И ей наверно виднее как оптимально это все писать/читать, иначе бы просто не было типа BLOB.

Когда-нибудь сравни производительность чтения из БД и из файла.

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

Верно! Нет никакой магии, только в случае с БД у тебя между файлом и приложением есть еще прослойка из БД (т.е. из хранилища и SQL) поэтому все это тормозит в десятки, а то и сотни раз.

Наоборот же, все данные бинарные, нюансы в интерпретации. Определяя тип ты подсказываешь СУБД как эффективно эти данные хранить и как их обрабатывать. Строка подразумевает приведение к некой кодировке, бинарь надо тупо получать и отдавать как есть

Именно. И внутри мускула варбинари и варчар - один и тот же тип данных. Отличия в нуюнсах обработки в SQL.

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

раздуваешь БД и замедляешь работу твой системы ради... а вот ради чего - не знаю

Заталкиваю двоичные данные файлов в БД ради единой системы доступа - на уровне БД, чтобы не придумывать параллельную с БД структуру на ФС для каждого пользователя.

Каждый пользователь приложения общается с БД от имени пользователя самой БД. Всё security, в том числе row level security делает только БД - ни приложение, ни ФС понятия не имеют о конечных пользователях. Соответственно, нет никаких данных уровня приложения по пользователям/паролям (утечки таблицы с данными авторизации с этой стороны быть не может по определению). Пользователи загружают/достают свои жпеги напрямую в БД. Миллионы пользователей не предусматривались и не нужны, конечно, изначально.

Это плохо? Серьезно, интересно услышать в чем тут может быть ошибка.

Toxo1 ()
Ответ на: комментарий от templarrr

Если по-твоему взлететь == стать номером один, то да, Python в web не взлетел

Скорее, взлететь = сильно подняться над базовым уровнем и вытеснить прямых конкурентов.

KRoN73 ★★★★★ ()
Ответ на: комментарий от Suntechnic

все это тормозит в десятки, а то и сотни раз.

Ты сравниваешь считывание файла по заранее известному пути с выборкой по запросу что ли? Ай, малацца! Ну да, статика быстрее, кто бы сомневался. А если тебе путь еще хитрожопо надо найти, то это ничего не даст кроме лишних телодвижений. Впрочем, я не призываю хранить видосики в БД. А бинарные данные разумного размера почему бы и нет.

anonymous ()
Ответ на: комментарий от Suntechnic

у тебя между файлом и приложением есть еще прослойка из БД (т.е. из хранилища и SQL) поэтому все это тормозит в десятки, а то и сотни раз.

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

anonymous ()
Ответ на: комментарий от anonymous

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

В общем случае - да. Просто потому что размер БД будет меньше, потребуется меньше кэша. Меньше будет загружена оперативка и в том числе она будет иметь больше места под буфер io.

Suntechnic ★★★★★ ()
Ответ на: комментарий от pawnhearts

большинство вопросов на StackOverflow по python2. Python 3 уже, на минуточку, 10 лет. Некоторые даже на 2.7 новые проекты начинают (чего я уже совсем не понимаю).
лично для меня python для серьезных задач таки все, пошел следом за Делфи. Причем именно из-за проблем совместимости даже на уровне неосновных версий (не язык, библиотеки)

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от Toxo1

Заталкиваю двоичные данные файлов в БД ради единой системы доступа ... Это плохо?

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

anonymous ()
Ответ на: комментарий от anonymous

Делай как удобнее

Это да. Так всегда и делал. А потом начал читать хабр, лор и опеннет и теперь почти ничего не делаю и всё время сомневаюсь в тех крохах, которые таки выдавливаю из себя.

В этом же приложении - с лица KnockoutJS, с попы Postgres. Между ними php. Измучился, чтобы написать php часть максимально близко к канонам ООП и прочих MVC. Так и не понял, зачем надо городить целый огород, чтобы сформировать десяток SQL-запросов и вернуть обратно ответ в json. Но в интернетах же совсем заплюют, если признаться, что в стиле php3 тебе писать удобнее.

Toxo1 ()
Ответ на: комментарий от Toxo1

Ну, честно говоря ORM таки удобнее чем «в стиле php3», причём заметно.

Тут штука в том что ORM самому писать не нужно, просто берёшь как есть и делаешь. Если хочешь/можешь — покажи код, покритикуем (конструктивно, честное октябрятское), подскажем как удобнее использовать ORM. Ну, если осилим :). Если тебе интересно конечно.

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

Хорошо. Один шут вся логика в триггерах написана. В PHP только CRUD, практически.

Вот такой кусок:

  $res = An::$an_db->resQuery(
                    'INSERT INTO dat_rent'
                    . ' (contract_number, contract_date, contract_owner_code, description)'
                    . ' VALUES'
                    . ' ($1, $2, $3, $4) RETURNING rent_id',
                    [
                        An::$an_filter->stringOrNull(\INPUT_POST, 'contract_number'),
                        An::$an_filter->dateOrNull(\INPUT_POST, 'contract_date'),
                        An::$an_filter->stringOrNull(\INPUT_POST, 'contract_owner_code'),
                        An::$an_filter->stringOrNull(\INPUT_POST, 'description'),
                    ]
                );
Как бы выглядел в готовых ORM?

Toxo1 ()
Ответ на: комментарий от Toxo1

орм который я использую (kohana framework), выглядел бы вот так

$d = ORM::factory('DateRent');
$d->values($_POST);
// либо $d->values($_POST, array('contract_number', 'contract_date')); для конкретного набора полей
$d->save()->rent_id

При этом нужно определить модель в файле application/classes/model/DateRent.php
class Model_DateRent extends ORM {
  protected $_table_name = 'dat_rent';
  protected $_primary_key = 'rent_id';

  public function stringOrNull($value) {
    return is_string($value) ? $value : NULL;
  }

  public function dateOrNull($value) {
    $d = DateTime::createFromFormat(MY_DATE_FORMAT, $value);
    return $d ? $value : NULL;
  }

  public function filters() {
    return [
      'contract_number' => [
	['strip_tags'],
	[[$this, 'stringOrNull']]
      ],
      'contract_date' => [
	[[$this, 'dateOrNull']]
      ],
      'contract_owner_code' => [
	['strip_tags'],	
	[[$this, 'stringOrNull']]
      ],
      'description' => [
	['strip_tags'],	
	[[$this, 'stringOrNull']]
      ]
    ];
  }
}

Если я ничего не напортачил с вызовами... синтаксис php во всей красе. Но обычно когда пишешь — это не проблема, так как и примеры перед глазами и в голове всё свежо.

Преимущества очевидны: все правила сгруппированы в одном месте, если ты скажем в двух местах делаешь сохранение или редактирования контакта, то при необходимости добавить например strip_tags, тебе нужно редактировать в одном месте всего. Кстати, в порядке конструктивной критики, strip_tags точно надо добавить, не забывай. Или ты при выводе стрипаешь?

Пришлось так же определить stringOrNull и stringOrDate собственные, потому как я не полез разбираться с твоей тулзой: можно было бы её в правило передать прямо вместо [$this, stringOrNull], к примеру, но я не понял на вскидку как там брать не из поста а просто проверить переданное значение.

Кода немного больше, но уже на втором запросе (тебе ведь надо где то в админке апдейтить это дело, верно?), кода станет меньше чем в стиле php3:
$d = ORM::factory('DateRent', @$_POST['id']); // либо берём существующий из базы, либо создаём новый, если id не пришёл
$d->values($_POST);
$d->save()->rent_id

AndreyKl ★★★★★ ()
Ответ на: комментарий от Toxo1

Кстати, если использовать соглашения (имя таблицы и имя внешнего ключа должно быть daterents и id соотвественно или надо допольнительно настраивать), внешние валидаторы и записать в одну строку, то кажется кода уж совсем немного больше

class Model_DateRent extends ORM {
  public function filters() {
    return [
      'contract_number' => [ ['strip_tags'], [[An::$an_filter, 'stringOrNull']] ],
      'contract_date' => [ [[An::$an_filter, 'dateOrNull']] ],
      'contract_owner_code' => [ ['strip_tags'], [[An::$an_filter, 'stringOrNull']] ],
      'description' => [ ['strip_tags'], [[An::$an_filter, 'stringOrNull']] ]
    ];
  }
}
13 строк против 12 у меня получилось. Что, согласись, выглядит очень хорошо.

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 4)
Ответ на: комментарий от AndreyKl

Спасибо.

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

Когда попадается в руки чужой код - суть понять могу, но никакого удовольствия не получаю. Допустим, при изменении структуры в БД, всё равно кучу всего надо перебирать. Хоть ORM, хоть стринги.

Плюс, если я правильно понимаю, ORM обычно предлагается, как унификатор (?есть такое слово?) для работы с различными БД. Т.е. - оно отбрасывает тонкие вещи. В частности в 9.5 появилась конструкция «INSERT ON CONFLICT DO UPDATE» - одним запросом. Если я знаю, что у меня БД будет на 9.5 я пойду и перепишу свою поделку под это, более изящное решение. А в случае со сторонним ORM? Ждать когда авторы переделают? Вносить свои правки в чужой код? Просто игнорировать особенности 9.5? Не понятно.

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

Вот примерно такие сомнения последнее время сны страшные наводят.

В любом случае - спасибо, интересно.

Toxo1 ()
Ответ на: комментарий от Toxo1

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

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

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();


Единственное что нужно поменять в ОРМ это функцию filters чтобы добавить правило обработки значения от пользователя. В отличие от кода в стиле php3.

И даже в варианте
$o = ORM::factory('RentDate', @$_POST['rent_id'])
$o->values($_POST, [...])

добавлять/удалять поля заметно проще, т.к. это всего навсего элемент массива, а не куча действий по эскейпу, валидации и конкатенации строк.

Остаётся ещё вывод и посылка данных на сервер. Но работы всё равно становится заметно меньше (процентов на 30% наверное), поэтому ОРМ однозначно выигрывает у стиля php3.

А так — пожалуйста, но зря ты упираешься, по моему. Я выбираю себе фреймворк и учу его, что позволяет писать код заметно быстрее и лушче. Несмотря на то что приходится потратить некоторое время на изучение фреймворка. Боюсь что с подходом php3 найти работу будет заметно сложнее. Хорошую работу, конечно, а не за 25 тысяч в месяц. И, объективно, это так и должно быть, потому что производительность труда программиста с использованием подобных (устаревших) технологий будет ниже, как ни крути.

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 2)
Ответ на: комментарий от AndreyKl

Вы со мной прям как с капризным дитём ) Ну, может и заслуживаю, всё правильно.

strip_tags - точно сознательно не делаю. Когда сдёргиваю аяксом и KnockoutJS по observable обновляет за-bind-енные элементы - оно не нужно (формы ввода). Когда формирую html средствами php - нужно (отчеты для печати). Поэтому обрабатываю на выходе - там так, там эдак.

Про «хорошую» работу (в смысле денег) - я уже понял и смирился. Мне бы свою, «нехорошую», уже теперь не просрать, пока есть ещё люди находящие причины мне деньги платить. И, кстати, я уверен, что фреймворки, ORM, PSR-1, PSR-2 и т.п. в большей степени имеют отношение не к производительности труда, а к.. «конвейеризации», унификации, к удобству контролирования и распределения задач, к легкой заменяемости самих исполнителей. Т.е. - больше к менеджменту, чем к программированию кода.
А я сам по себе. Всегда был сам по себе. И швец, и жнец, и на дуде игрец, и сам себе контроллер. Пока есть кому ещё нужен. Но уже прям на грани, это тоже да.

Toxo1 ()
Ответ на: комментарий от Toxo1

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

Кайф только в том, что кодер без малейшего понимания SQL может как то работать с РСУБД в «привычном ему стиле». Ну это так заявлено, на самом деле конечно ниче он не может и будет выгребать двойную сложность: самого запроса и его выражения в терминах ORM. Эта абстракция конкретно так течет, просто потому что выразительности ЯП не хватает. Вдумайся в абсурдность ситуации: высокоуровневый DSL для работы с реляционными данными оборачивают низкоуровневой императивной лапшей. Это как ассемблер, компилируемый в си. Прикол еще в том, что запросы на таком квази-sql все равно надо выделять в отдельный слой. Если их разбрасывать вольно по всему коду, это ничем не лучше сырых запросов. Итак, взяли и на ровном месте увеличили сложность и ухудшили выразительность. Все ради чего? Чтобы перепаковывать результаты выборки в объекты? Так для этого можно написать тончайший слой обработки без кошмарных текущих паттернов типа ActiveRecord.

anonymous ()
Ответ на: комментарий от Toxo1

И да, конечно от орма никуда не сбежишь потому что «все так делают». Это как шаблонные движки на PHP. Зачем, если сам PHP и есть шаблонный движок? Молчи, так надо. Кстати, при суровой оптимизации орм как раз часто выкидывают и переписывают все на хранимках. Есть даже мнение, что орм не более чем инструмент прототипирования.

anonymous ()
Ответ на: комментарий от aiive

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

aiive ()
Ответ на: комментарий от anonymous

Все это есть в чистом php.

Точно? Если я в твиге сделаю {{ var }}, то вывод автоматически будет заэскейплен. Если я в пыхе сделаю <?= $var ?>, то нет.

И как на пыхе будет выглядеть следущее(берется шаблон layout.html, и переопределяется в нем только один блок).

{% extends "layout.html" %}

{% block content %}
    Content of the page...
{% endblock %}

aiive ()
Ответ на: комментарий от aiive

Если я в твиге сделаю {{ var }}, то вывод автоматически будет заэскейплен. Если я в пыхе сделаю <?= $var ?>, то нет.

А в чём проблема написать <?=e( $var )?> или что-то в этом роде? Чем принципиально отличается {{ от <?=e(

И как на пыхе будет выглядеть следущее(берется шаблон layout.html, и переопределяется в нем только один блок).

Посмотри как сделано в пресловутом wordpress.

no-such-file ★★★★★ ()
Ответ на: комментарий от anonymous

Toxo1, во первых, прошу прощения, что на «ты».

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

Изучение фреймворка займёт определённое время. Вероятно, в неспешном темпе месяца 3. Потом можно решать,стоит ли его использовать в новых проектах. Для старых проектов добавлять фреймворк по моему имеет смысл только тогда когда у программиста ну очень хороший опыт с фреймворком и он понимает что делает.

Так же хотел бы ответить на вашу мысль про унификацию. Действительно, пмсм, поддерживать решение типа MVC проще чем навелосипеженную отдельным программистом «архитектуру» зачастую густо замешанную на глобальные переменные с обильным дублированием и, в худшем случае, с очень высокой связностью. Кажется, действительно будет кое какая экономия за счёт того что не нужно понимать где что искать (или это понять можно тривиально). Но это как мне кажется следствие хороших и плохих «архитектур», а не столько именно унификации. Т.е. мир тяготеет к решениям которые проще и понятнее, когда у сложных нет преимуществ окупающих сложность.

Но что до sql, то по моему он ничуть ни менее «унифицирован» чем orm. Т.е., мне кажется, мы с вами сошлись бы на мнении что найти программиста могущего в тот код который написали вы не сложнее чем такого кто мог бы в тот код что написал я. Т.е. взаимозаменяемость она как бы не страдает от чистого sql. И тут мне кажется всё же играет роль то что не нужно писать sql руками и меньше дублирование кода. Причём всё это имеет такой «квази-декларативный» характер: просмотреть набор правил, названия таблиц и т.п. обычно заметно удобнее чем разбираться в алгоритме или хотя бы в sql запросе. Что ведёт к меньшему количеству ошибок, меньшему объёму кода ну и соотвественно большей производительности труда.

Т.е. по моему унификация - скорее следствие: побеждают хорошо зарекомендовавшие себя решения, ну а их разнообразие ограничено.

Так же хотелось бы отметить такой момент: несмотря на то что анонимус, как кажется, печатает просто какие то наборы слов не несущих особого смысла, всё таки рациональное зерно в его словах есть, по моему мнению. И оно было уже тут высказано после анонимуса ещё раз: орм прослойка довольно сложна, и честно говоря теряет смысл тем дальше чем дальше дело отходит от CRUD. Более продуктивным подходом конечно было бы обернуть ваши запросы в отдельный сервис и как то обобщить немного. Что то вроде

class RentService {
  public function filterRent($poRent) {
    return [
      An::$an_filter->stringOrNull($poRent->contract_number),
      An::$an_filter->dateOrNull($poRent->contract_date),
      An::$an_filter->stringOrNull($poRent->contract_owner_code),
      An::$an_filter->stringOrNull($poRent->description)
    ]
  }

  public function createRent($poRent) {
    $res = An::$an_db->resQuery(
      'INSERT INTO dat_rent'
      . ' (contract_number, contract_date, contract_owner_code, description)'
      . ' VALUES'
      . ' ($1, $2, $3, $4) RETURNING rent_id',
      $this->filterRent($poRent)
    );
  }

  public function updateRent($poRent) {
    An::$an_db->resQuery(
      'UPDATE dat_rent'
      . ' SET contract_number=$1, contract_date=$2, contract_owner_code=$3, description=$4)'
      . ' WHERE'
      . ' rent_id=$5',
      array_merge($this->filterRent($poRent), [$poRent->rent_id])
    );
  }
}

При этом можно ловить и передавать объект посланный в JSON-виде, например
$rentSrv->createRent(json_decode($_POST['rentObj']));

Это позволит избежать дублирования и не заморачиваться с изучением ORM. Что, для более-менее сложных случаев (когда нужны транзакции и/или нетривиальные запросы), может быть, на мой взгляд, вполне оправдано. Правда, sql придётся писать руками. Но для динамически-типизированного языка это вряд ли большое горе.

что же до «и жнец и на дуде игрец» - мне кажется многие так работают. Или периодически так. Тем не менее фреймворки удобнее)) пмсм, конечно.

---

Вообще, отвлекаясь от php и уже не лично вам, Taxo1, из серии «самому писать sql» мне больше всего понравился Anorm ( https://playframework.com/documentation/2.6.x/ScalaAnorm ), в изучении очень прост (оно и понятно, sql + немного сверху) и компилятор делает довольно много проверок, что несомненно весомый плюс.

Ещё пробовал myBatis, там запросы в xml пишутся. Идея интересная, но я бы предпочёл полноценный встроенный в язык и проверяемый компилятором при компиляции dsl.

Из подобного я пробовал на реальном проекте Squeryl ( http://squeryl.org/ ) показался очень интересным и удобным. Но если там заблудишься, то без бутылки найти дорогу на свет божий будет трудно.По крайней мере у меня так. Кроме того, емнип, зачастую дб-спецефичных фич в нём не было, что тоже не совсем удобно.

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)