Какие базы данных поддерживают JSON-схемы, по аналогии с ElasticSearch?

Question

[Alex XYZ]

Всем привет.

Из известных "мне" баз данных встроенная поддержка JSON-схемы есть только в ElasticSearch. Есть ли ещё какие-то БД, которые так же поддерживают схемы JSON при сохранении?

P.S.
Речь идёт именно о схемах, а не о типе JSON, которые есть даже в реляционных БД. Существующие способы хранения json в реляционных базах только проверяют валидность json, а не соответствие схемы.

Answer 1

[lega]

В MongoDB добавили какую-то схему/валидацию.

Comments

[Alex XYZ]

Вы про это? https://docs.mongodb.com/manual/reference/mongodb-...
Вы не в курсе, а массивы такая валидация поддерживает?

[lega]

Захаров Александр: скорее про это https://docs.mongodb.com/v3.2/core/document-validation/

[lega]

Я не сторонник, чтобы дополнительно нагружать центральное место. Проверку нужно делать в серверном приложении или на уровне драйвера.
А кто базу корежит напрямую - сами буратины. Так и схема не спасёт, т.к. всегда можно поправить файлы БД напрямую.

Answer 2

[sim3x]

В реляционных субд нет такого типа как жсон. Он есть в реляционно-обьектных СУБД типа postgresql

ЖСОН-схема - попытка сделать из noSQL субд SQL

The schema in Elasticsearch is a mapping that describes the the fields in the JSON documents along with their data type, as well as how they should be indexed in the Lucene indexes that lie under the hood.

Такое можно организовать в виде процедур в любой нормальной субд

Comments

[Alex XYZ]

>> Такое можно организовать в виде процедур в любой нормальной субд
У меня так и сделано, но согласовывать процедуры и схему кажется гораздо затратнее, чем поддерживать схему в актуальном состоянии. Поэтому я хочу уйти от этого. Кроме того, если руками впихнуть что-то в обход схемы, то последствия как правило печальные.
С одной стороны очень хорошо, когда БД следит за схемой, но с другой стороны запросы к БД как у Elastic ну очень тяжело формировать.

>> ЖСОН-схема - попытка сделать из noSQL субд SQL
по-моему не совсем верно. Основная фишка в SQL - это связи, которых нет в NoSQL, но с другой стороны иногда реляционные связи не нужны, но в "нормальных" БД приходится ветвление делать на реляционных отношениях, а потом собирать обратно процедурами. Что не всегда бывает удобно - вроде как и отношения есть, а вроде как и отношения не используется по прямому назначению.