Ответ

Sumo 29.06.2012 10:31 / 29.06.2012 10:55

max_rip, я написал текст по следам всего топика, а не в ответ на ваше сообщение. :)

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

Основная задача ORM'а — связать объекты в программе с табличками в базе данных. Защита — это второй вопрос, который для Парсера менее актуален, чем для других языков, поэтому мы можем делать механизм защиты сильно проще.

Как раз только select, у меня 99% работы сайта только чтение.

Если бы выборки были без условий или с фильтрацией по одному значению первичного ключа, то проблем бы не было. Но нам ведь приходится делать выборки со сложными условиями (только активные клиенты, с датой заключения договора не больше года, имеющие 5 сотрудников и т.д.) для которых приходится писать отдельные методы или параметризировать функцию и строить запрос динамически (Парсер с этим отлично справляется), для каунтов приходится писать отдельные методы и т.д. и т.п. Но вот удобно ли это?

Насколько я понимаю у Михаила пару раз возник вопрос в переносе БД из одной системы в другую, но мы не знаем подробностей и причин.

Знаем, Миша про это писал не раз: он разрабатывает WVC (Имприматур I, если не ошибаюсь), которая может быть запущена у заказчика на разных хостингах и с разными базами данных, поэтому для него важно, чтобы запросы были переносимыми. Ситуация достаточно часто встречается. Если ориентироваться на более-менее стандартный SQL, то можно строить вполне переносимые системы.

К тому же ориентация на разные БД ограничивает нас в использование каких-то моментов, которые реализованы только в какой-то БД.... Зачем же лишать себя таких вкусностей?

Большинство реализаций ОРМов для других Питона, Руби, ПХП и других языков, позволяют писать свои запросы, если есть необходимость сделать какой-то нестандартный выверт, задать хинты для оптимизатора запросов и сделать еще массу вещей, которые могут понадобиться в редких случаев. Никаких вкусностей мы себя не лишаем. И вопрос только в том, насколько мы гибко напишем сами классы.

но вот насколько медленнее он будет работать?

Это зависит от реализации, но мои тесты показали, что реализация шаблона «table data gateway» получается очень быстрой, поскольку генерация запроса задача не очень сложная. У меня в коде замена старых методов доступа на ОРМ вообще не изменила скорость работы (разница показаний была в пределах погрешности измерений). Кроме того, Парсер очень быстрый и бояться каждого «лишнего» вызова функции или регулярного выражения не стоит. :)

p.s. Если кому-то интересно, то в pf'е сейчас есть реализация несложного ОРМа — http://code.volchkov.net/parser3-pf/src/47d1dd96c0b0/sql/orm. Я его потихоньку допиливаю, например, добавляю агрегации, но базовый функционал вполне работоспособен. Работает с Парсером не ниже 3.4.2.

---