Тезис про контроль интересный...

Sumo 29.06.2012 08:48

[Сейчас будет длинный флеймовый пост. :)]

В этой теме уже несколько раз всплывала идея, что использование низкоуровневых средств дает больший контроль. На мой взгляд это неверная посылка. При работе с данными есть два аспекта: интерфейс доступа к СУБД (то, что мы обсуждаем в этой теме) и
формирование sql-запросов — «контроль», для каждого из них, имеет разный смысл.

Для доступа к СУБД в Парсере реализован универсальный механизм, который позволяет однообразно реализовать и кешировать соединение с серверами (через драйверы и оператор connect), реализует единый интерфейс для запросов и автоматизирует сериализацию выборок в базовые объекты (string, int, hash, table), а система «грязных данных» обеспечивают защиту от всяческих инъекций. Интерфейс очень удобный, но дает ли он нам тот самый «контроль»? Не дает. Мы не можем базовыми средствами получить информацию о том какие запросы и в каком порядке выполнялись, сколько на них потрачено времени и памяти, какой объект был возвращен. Необходимо следить самостоятельно обернут ли код, делающий запросы в connect: стандартное решение «обернуть весь код страницы в connect» не подходит, если нам не для каждого обращения к странице нужно лезть в базу данных (хотим взять данные из кеша или страничка с ошибкой). Реализация транзакций требует много «лишнего» кода: надо не забыть отключить auto_commit в mysql сделать begin, а потом commit, автоматический ролбэк у парсера есть, но он срабатывает на закрывающей скобке конекта, т.е. надо дополнительно заворачивать код в connect (а он еще и будет вложенным!) и т.д. Оператор cache не умеет кешировать данные и надо вручную возиться с сериализацией данных и сохранением их на диск. А если нам надо глобально отключить кеш для запросов?

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

Второй аспект — формирование sql-запросов. Классы доступа к БД дают абсолютно такой же контроль над запросами, что и нативные методы, поскольку никак не влияют на сами запросы и являются только прокладкой к базовым методам языка. Они несколько облегчают написание переносимых запросов (современный субд, даже при заявленной поддержке стандартов, отличаются в деталях реализации сиквела) за счет наличия функций-генераторов для дат, строк и некоторых других функций. Никто не мешает писать в запросах многоуровневые джоины, подзапросы и т.п. Синтаксис Парсера позволяет нам делать очень сложные шаблоны запросов без всяких плейсхолдеров за счет своего синтаксиса. Это очень большой плюс, но минус в том, что хотелось бы видеть что за запрос мы отправляем на сервер, а тут без логирования уже тяжело и без классов это придется делать вручную в коде. Про профилирование запросов уже писал раньше — без него написать систему без проблем с производительностью можно только чудом. Разве это контроль? Нет — это средство внести в код большое количество ошибок не решив основной проблемы. :)

Но даже использование sql-классов не дает нам контроля за слоем доступа к данным (модели). Думаю многие замечали, что подавляющее большинство запросов, которые мы пишем в своем коде, это простейшие CRUD-операции (create, read, update, delete). Они повторяются из проекта в проект, никаких тайных знаний не содержат, одним словом — рутина. Много времени тратится на отладку: то имя поля в базе перепутаем, то параметр метода называется не так, как мы рассчитывали, то надо не забыть всякие автоматические поля обновлять (created_at, updated_at). Возни много, толку мало. Помочь в данном случае могут всяческие автоматические генераторы sql'я, ORM's и пр. Но это уже совсем другая история... :)

---