Язык создания запросов(dbSimple++).

[Фанат]

Предлагается завести ключики ?a для перечисления ключей через запятую

Мне кажется, в mysql это не нужно. Множественный инсерт - единственный случай, который можно придумать.

и ?v для перечисления значений через запятую?

а вот для этого у меня как раз служит ?a

для максимально возможного разнообразия запросов.

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

 

[ksnk]

Мои возражения по классу:

- большое количество "массивных" плейсхолдеров. Для простых типов переменных их количество, абревиатура и использование логично и оправдано, там ограниченное количество типов, строки числа и поля, возможно даты и плавающие, все на месте. А для массивов каждый из них заменяет собой целый шаблончик со своими конструкциями с неопределенным типами у нее внутре... Нелогично, imho, и нерасширяемо. Цель класса-обертки - инкапсулировать в себе ВСЕ, чтобы не потом лазить в код и не дописывать новые шаблончики.

- отсутствие возможности выбора номера параметров (а-ля sprintf). Хотя реализация такой фенечки проста и не особенно страшно выглядит в шаблонах. Вероятно, можно пристроить какой-нибудь декоратор/разделитель - $, как в sprintf, но, imho, и так все понятно и вроде не мешает разбору регулярками. Если массив передается переменной, это как бы не сильно напрягает, а вот явно указать массив в параметрах (результат выполнения функции) уже не всегда возможно.

 

[fixxxer]

getByKey - это вообще какая-то фигня, попытка подменить SQL. "Давайте выберем тыщу записей, а потом ручками отфильтруем нужные"

В таком виде да. Но бывает нужно сконвертировать плоскую структуру, полученную после джойнов, во вложенные массивы.
В моем велосипеде есть 3-й опциональный параметр к getAll:

getAll($query_template, $args, $group_keys)

вида

$group_keys = array(
     'group_id' => INF,
     'id' => 1
);

где INF обозначает "одному значению group_id соответствует множество строк", 1 - "одному значению id соответствует одна строка". (Модификатор 1/INF, конечно, имеет разумный смысл только для последнего элемента group_keys, но читабельнее я не придумал). То есть, для результата вида

group_id    id      value
--------    ------  --------------
1           1       foo
1           2       bar
2           3       bazz

получим

array(
    // group_id
    '1' => array(
        // id
        '1' => array('group_id' => '1', 'id' => '1', 'value' => 'foo',
        '2' => array('group_id' => '1', 'id' => '2', 'value' => 'bar',
    ),
    '2' => array(
        '3' => array('group_id' => '2', 'id' => '3', 'value' => 'bazz',
    )
)

Не помню, есть у тебя что-то подобное или нет=)

 

[Фанат]

чтобы не потом лазить в код и не дописывать новые шаблончики.

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

Это то самое фундаментальное расхождение, которое и определяет различия в реализации. И найти здесь общий знаменатель не удастся.

 

[Фанат]

Не помню, есть у тебя что-то подобное или нет=)

Нету. Я подумаю об неё.
Кто-то мне предлагал, то ли Зеркмс, то ли ещё кто-то.

Но конкретно эта getByKey - это тупо цикл с фильтрацией внутри него по условию из параметров.
Что оно забыло классе для работы с БД - загадка.

 

[ksnk]

Я считаю, что надо один раз прописать в классе, чтобы потом много раз в коде писать простые вызовы.

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

Ты считаешь наоборот - в коде приложения постоянно надо извращаться заради простоты кода класса.

Под кодом приложения понимается сам sql-шаблон? Мне кажется - довольно просто. Впрочем, twig мне тоже казался достаточно простым в качестве sql-шаблонизатора.

 

[Фанат]

Под кодом понимается код приложения.
От составления запроса до получения результата.

$sql  = "INSERT INTO ?n SET ts=unix_timestamp(), ip=inet_aton(?s), ?u";
$db->query($sql, $table, $ip, $data);

или

$data = $db->getInd('id', 'SELECT * FROM ?n WHERE id IN (?a)', $table, $ids);

 

[fixxxer]

ksnk
Я в качестве sql-шаблонизатора уже много лет использую blitz, мне все говорят, что я извращенец.

 

[ksnk]

Под кодом понимается код приложения.
От составления запроса до получения результата.

Та моя функция ( _ ) - часть используемого мной драйвера базы данных. Парсер запросов.

С точки зрения пользователя моего драйвера код выглядит так ( заменил на квадратные скобки заради лучшего вида)

ENGINE::db()->insert("INSERT INTO ?x SET ts=unix_timestamp(), ip=inet_aton(?s), ?[?k=?]", $table, $ip, $data);

или

$data = ENGINE::db()->select( 'SELECT `id` FROM ?n WHERE id IN (?[?2])', $table, $ids);

для варианта getInd у меня сейчас нету адекватной замены.

Вообще говоря - такой-же код. разница только в самом sql-шаблоне.

 

[Фанат]

Ну вот это уже сильно лучше того, что было. только не ?x, а ?k

 

[hell0w0rd]

Не соглашусь про getByKey, вчера ночью его дописал и считаю что нужная штука. Неужели у вас никогда небыло потребности вытащить много данных из базы, а потом их рассовать в разные места? Самое простое - мне нужно вытащить 2 менюшки. Они лежат в 1 таблице. Тащу 1 запросом, а потом с помощью этого хелпера беру 1, а затем вторую.
Просто такую штуку надо использовать по назначению(как описал выше), а не как замену WHERE

 

[fixxxer]

это должно быть во view

 

[hell0w0rd]

это должно быть во view

хм, в принципе да)

 

[ksnk]

Ну вот это уже сильно лучше того, что было. только не ?x, а ?k

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