Comments 8
Осталось довести до нужной кондиции ORM фреймворки, чтобы работать с этим типом без танцев с бубном.
NoSQL != «не реляционная»
С чего вы взяли, что тип данных json сразу делает базу «noSQL»?
Честно говоря, синтаксис отвратный. Очень странно смотрится рядом с операциями с такими структурами данных в других БД. И еще не добегая к ORM попахивает настоящими танцами с бубном.
Не понимаю одного: зачем?
Зачем в реляционной БД noSQL заморочки? Она от этого станет eventualy-consistent с multi-master маштабированием хотябы до десятка машин? Нет!
Смотришь на мир noSQL систем — они все пытаются придумать SQL-like синтаксис, эти наоборот.
noSQL — не потому что SQL как язык плох, а потому что реляционная модель БД — накладывает существенные ограничения на маштабируемость. Иногда не нужно ACID, но нужен кластер на 100500 серверов.
А тут… Нет конечно понятно — «у нас уже есть инфраструктура на PostgreSQL, но нам вот тут срочно понадобилось бонусом хранить в виде документов что-то» не переходить же нам на что-то другое.
Зачем в реляционной БД noSQL заморочки? Она от этого станет eventualy-consistent с multi-master маштабированием хотябы до десятка машин? Нет!
Смотришь на мир noSQL систем — они все пытаются придумать SQL-like синтаксис, эти наоборот.
noSQL — не потому что SQL как язык плох, а потому что реляционная модель БД — накладывает существенные ограничения на маштабируемость. Иногда не нужно ACID, но нужен кластер на 100500 серверов.
А тут… Нет конечно понятно — «у нас уже есть инфраструктура на PostgreSQL, но нам вот тут срочно понадобилось бонусом хранить в виде документов что-то» не переходить же нам на что-то другое.
Ну хотя бы потому что это удобно. Не всем нужен кластер на 100500 серверов или вообще кластер, а вот schema-less явно удобно, еще удобно взять данные из базы в виде json, этот же json тут же отдать шаблонизатору без каких-либо промежуточных действий
Ну может если нужна schema-less, то видимо выбор *реляционной* СУБД PostgreSQL, это не совсем правильное решение? Так то и микроскопом гвозди можно забивать, и даже держаться удобно.
Я не спорю иметь в системе нечто, что позволит городить по сути костыли: «мы выбрали инструмент для этого не предназначенный» но нам так удобнее/ибо было/умеем работать — я понимаю. Но как то «еще более мощные инструменты» — не тянет.
Уж лучше бы в сторону масштабируемости глядеть и какие нибудь проекты типа пулинга клиентов а-ля pgpool или кластеризации аля Postgres-XL до ума доводить.
Я не спорю иметь в системе нечто, что позволит городить по сути костыли: «мы выбрали инструмент для этого не предназначенный» но нам так удобнее/ибо было/умеем работать — я понимаю. Но как то «еще более мощные инструменты» — не тянет.
Уж лучше бы в сторону масштабируемости глядеть и какие нибудь проекты типа пулинга клиентов а-ля pgpool или кластеризации аля Postgres-XL до ума доводить.
Sign up to leave a comment.
JSON и PostgreSQL 9.5: с еще более мощными инструментами