Прошу прощения, невнимательно прочитал вопрос и ответил на «почему вы не использовали MongoDB».
А отличается наше решение тем, что мы продолжаем использовать PostgreSQL со всеми его фишками и наработками со стороны приложения, и тем, что не надо ничего мигрировать, кроме нескольких таблиц, для которых гибкие схемы и нужны
Основная причина — для наших задач хороши реляционные бд: транзакции, ссылки на другие таблицы, нецелесообразность переноса всех остальных данных приложения, готовая, заточенная инфраструктура — ORM, кеширование, репликация и партицирование. Выборки по большому количеству непредсказуемых критериев, т.е. то, для чего старые добрые реляционные дб хороши.
Так что добавлять новую технологию в свой стек особого резона не было.
Не так давно решали аналогичную задачу, с некоторыми отличиями — динамическая схема нужна только для части колонок, и важна производительность на довольно сложных выборках (много критериев фильтрации + сортировка).
EAV был отброшен как непрактичный (и вероятно ещё и очень медленный). XML и hstore как слишком медленные и требующие много памяти для хранения. Остановились на JSON, накидали функции для его поддержки на perl, а позднее на c.
Во-первых, «сделать классное приложение» плохая цель. Лучше, например, «сделать приложение хорошо удовлетворяющее такую-то потребность пользователей». Во-вторых, если дизайнер об этой цели не знает, то он нарисует ерунду.
По моему опыту, то, что дизайнеры считают дизайном, и то, что разработчики считают разработкой, сильно пересекаются. В итоге, каждый считает, что он играет определяющую роль, а другая партия «тоже важна, чтобы реализовать все детали» :)
Я же не спорю, что возражение валидное. Но любой известный приём можно и не использовать, а вот использовать то, о чём даже не слышал, несколько затруднительно.
То же самое можно сказать про любой фреймворк, библиотеку или просто собственные наработки внутри любого достаточно крупного проекта. Однако народ пишет на рельсах, django и jQuery, появляются и широко используются даже такие расширения языка как Moose и меняющие парадигму библиотеки как underscore.js, async.js и Functional Java. А некоторые так и вовсе пишут на разных лиспах, где расширение синтаксиса — повседневная процедура.
А если отбросить теоретические рассуждения, то мы уже используем подобный подход в своей работе. В команде 5 человек, пока никто не застрелился. Кроме того, подобные техники абстракции поощряются несколькими моими open source библиотеками, и люди их используют без проблем.
Так что, хоть некий порог и добавляется, но это вполне практичные вещи.
Мысли из головы, но вот, например, как можно реализовать try/catch в перле. Ещё можно почитать про with в питоне, про использование блоков в ruby, ну и для полного просветления стоит познакомится с макросами в лиспе.
А отличается наше решение тем, что мы продолжаем использовать PostgreSQL со всеми его фишками и наработками со стороны приложения, и тем, что не надо ничего мигрировать, кроме нескольких таблиц, для которых гибкие схемы и нужны
Так что добавлять новую технологию в свой стек особого резона не было.
EAV был отброшен как непрактичный (и вероятно ещё и очень медленный). XML и hstore как слишком медленные и требующие много памяти для хранения. Остановились на JSON, накидали функции для его поддержки на perl, а позднее на c.
Если интересно могу написать пост об этом.
А в джанге баги я ловил и правил, не без этого :)
А если отбросить теоретические рассуждения, то мы уже используем подобный подход в своей работе. В команде 5 человек, пока никто не застрелился. Кроме того, подобные техники абстракции поощряются несколькими моими open source библиотеками, и люди их используют без проблем.
Так что, хоть некий порог и добавляется, но это вполне практичные вещи.
withв питоне, про использование блоков в ruby, ну и для полного просветления стоит познакомится с макросами в лиспе.