Пыхотред

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

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

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

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

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

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

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

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

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

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

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

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

Аргументы уровня РПЦ примерно...

Ты путаешь именн Binary Data с Binary Large Object. BLOB это бинарные банные, но бинарные данные это не обязательно BLOB.

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

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

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

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

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

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

SELECT бинарное_поле FROM любая_таблица

А что все-таки будет? Мне просто интересно, но не настолько чтобы ставить себе php))

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

Выборка мне нужна не по бинарным данным, но мне нужны бинарные данные по выборке.

Я еще поверю - ключ. Но данные шифрованные зачем?

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

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

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

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

Давай BOOLEAN тоже назовем Binary Data. А чо нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет кода на CPAN - пшёл вон.

Понятно, позвони +7 (495) 670-85-21, запишись на приём

Понятно

Вот и иди, раз понятно.

Я просто читаю твои ответы и думаю, что ты малолетний идиот.

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

Смелое заявление. Пруфов я просить, конечно, не буду.

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

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

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

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

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

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

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

Хорошо. Один шут вся логика в триггерах написана. В 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'),
                    ]
                );

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

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

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']]
      ]
    ];
  }
}

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

Кстати, если использовать соглашения (имя таблицы и имя внешнего ключа должно быть 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']] ]
    ];
  }
}

Спасибо.

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

Когда попадается в руки чужой код - суть понять могу, но никакого удовольствия не получаю. Допустим, при изменении структуры в БД, всё равно кучу всего надо перебирать. Хоть 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-программисту об этом думать не надо?

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

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

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

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

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, [...])

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

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

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

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

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

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

Шаблонные движки предоставляют возможности, которых в чистом пхп нет

Например?

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

Мужик, индусокодерам (не зависимо от их национальности и цвета кожи) это объяснять бесполезно )))

Например?

Наследование шаблонов, автоматический эскейпинг всего вывода, например.

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

для postgres посмотри Pomm https://github.com/pomm-project/Foundation/blob/master/documentation/foundati...

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

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

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

{% extends "layout.html" %}

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

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

Правильный ответ «как говно»

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

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

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

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

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])
    );
  }
}

$rentSrv->createRent(json_decode($_POST['rentObj']));

---

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

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

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