[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Конструктор запросов.
Страницы: 1, 2
twin
Свернутый текст
Чет скучновато стало на форуме. Не желаете напинать дядю Колю за ересь и крамолу? biggrin.gif


Забросил я свое творение на целых полгода. Все недосуг было. Но вот накатило вдохновение, и я собрал конструктор запросов. Правда так и не понял его полезность, но об этом позже. Раз должно быть, пусть будет.

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

Если захочется взглянуть на код, он тут.

Пока работает только с PDO и MySQL. Но это дело наживное. smile.gif

Ну и мысли вслух.

Я вот так и не понял, в чем его полезность. За всю историю холиваров слышал только один более-менее убедительный довод. Что с ним удобно собирать запросы в разных методах и даже компоненах, таская его в виде объекта. Тут да, полезность неоспорима. Другой вопрос, что такая архитектура на любителя, но не суть. А что еще?

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

Смена СУБД на рабочем проекте - дело форсмажорное. Положить на алтарь этой паранойи львиную долю возможностей СУБД... Увольте. Не для того меня мама родила. smile.gif

Ведь чтобы написать кроссплатформенный запрос, нужно учесть все особенности. И дело тут не в синтаксисе, это худо-бедно поправимо. Дело в особенностях. Допустим Pоstree не поддерживает ON DUPLICATE KEY UPDATE. Соответственно его нельзя юзать в запросах. Ну и естественно нет в конструкторе. И наоборот. Куча возможностей Pоstree чужда MySQL. А значит и про них можно забыть.
Свернутый текст
Где то заплакал один Сережа biggrin.gif


Так что в итоге остается куцое пересечение кучи поддерживаемых СУБД. И ради чего это? Должны быть веские доводы для такой добровольной кастрации. И довод о смене СУБД на рабочем проекте никак сюда не вписывается.

А что еще... Автоматическое экранирование? Ну ладно, для ленивых. Так ведь и тут не все просто. Конструкторы не все эканируют. Приходится изгаляться со всякими двойными скобками и пр.

Что касаемо привязки параметров с их эскейпингом, так это сейчас и нативные драйвера делают. Это анахронизм. smile.gif

Больше и в голову ничего не идет. Вобщем и целом я понял так. Использовать эту шнягу нужно только тогда, когда действительно припечет. А в быту - ну её.

Мне всегда такие вещи ассоциируются с выражением: "смотри как я умею!". Мол 21-й век, нативные запросы - отстой, все реальные поцыки пишут на билдерах. Код получается крутяяяяк! Один товарищ так и заявил: посмотри какой код, разве это не прекрасно? smile.gif

А суть копнуть - пустышка. Ресурс только жреть. user posted image

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.