В чем заключаются недостатки SQL :: Interp over SQL :: Abstract?

Question

В настоящее время я смотрю на некоторые легковесные модули абстракции SQL.Мой рабочий процесс таков, что я обычно пишу запросы SELECT вручную и запросы INSERT / UPDATE через подпрограммы, которые принимают хэши.

Оба эти модуля кажутся идеальными для моих нужд, и мне трудно принять решение. SQL :: Interp утверждений SQL :: Abstract не может обеспечить полную выразительность в SQL, но не обсуждает другие различия.

Есть ли у него какие-либо недостатки?Если да, то что?

Answer 1

Я использовал SQL :: Abstract более года, а затем переключился на SQL :: Interp, который я придерживался с тех пор.

SQL :: Abstract возникли проблемы со сложными предложениями.Для тех, которые он может поддерживать, вы получите гнездо символов "(" "[" и {", которые вы мысленно перевели обратно на значение" И "," ИЛИ "или фактически круглые скобки.

SQL :: Interp не имеет таких ограничений и не использует среднее представление. Ваш SQL выглядит как SQL с переменными связывания там, где вы хотите. Он работает как для сложных запросов, так и для простых. Я считаю, что SQL :: Interp особенно приятен в использованииКомбинация со встроенной поддержкой DBIx :: Simple . DBIx :: Simple + SQL :: Interp - дружественная и интуитивно понятная замена для использования необработанного DBI. Я использую комбинацию в 100 000k + LoCВеб-приложение mod_perl.

Answer 2

Я не могу говорить с SQL :: Interp, но я использую SQL :: Abstract, и это довольно хорошо. В сочетании с DBIx :: Connector и простым старым DBI я смог полностью исключить использование ORM в моей системе с очень небольшим недостатком.

Единственное ограничение, с которым я столкнулся, это то, что нельзя напрямую писать запросы GROUP BY (хотя это легко сделать, просто добавив к сгенерированному запросу, а запросы LIMIT обрабатываются расширением SQL :: Abstract :: Limit .