Библиотека хранения JSON данных EJDB

Один я прочитал «Хреновые коллекции JSON объектов»?

в чем разница между этим и mongodb?

встраиваемо

Очередная попытка пропихнуть json в серьёзную сферу. Неужели кому-то нужны все эти костыли, когда для xml всё давно написано?

Выбор, как обычно, между написано, но хреново и тем, что здорово, но не дописано, не отлажено и, возможно, никогда не взлетит.

Сама идея прекрасна. Это такой sqlite, которым sqlite задумывался и был бы сделан, если бы не реляционизм головного мозга его авторов.

реляционизм головного мозга

А у кого-то (судя по моде на NoSQL) реляционофобия.

Не вижу ничего плохого в концепции РСУБД, в том числе для относительно небольших хранилищ. Ладно, кому-то не нравится конкретный sqlite (мне - понравился), но ведь и раньше были и Paradox, и dBase/FoxPro, и для большого класса «настольных» задач это работало...

А у кого-то (судя по моде на NoSQL) реляционофобия.

Вопрос не в фобиях, а в соответствии решения тем требованиям, которые ставит задача.

Не вижу ничего плохого в концепции РСУБД, в том числе для относительно небольших хранилищ.

Большие или маленькие, это опосредованная характеристика. Гибкость схемы, которую требуют настольные применения, вот что плохо переносит РСУБД.

Ладно, кому-то не нравится конкретный sqlite (мне - понравился),

sqlite, это пример образцово выполненного проекта. Написали, отладили, сделали море биндингов и внесли в кучу дистров. На выходе полный вин. Тем не менее, sqlite представляет собой некий недокомпромис. Взяли таблицы и запрросы из РСУБД и выкинули обязательные типы столбцов, как в nosql. Плюсов от этого решения почти нет, а минусы в виде неявных ограничений все на месте.

но ведь и раньше были и Paradox, и dBase/FoxPro, и для большого класса «настольных» задач это работало...

Не аргумент. Еще раньше на столах были счеты и для большого класса «настольных» задач это тоже работало...

Вопрос не в фобиях, а в соответствии решения тем требованиям, которые ставит задача.

А какие новые требования появились для встраиваемых/десктопных/мобильных и прочих задач? NoSQL решения стали популярны исключительно из-за того, что с ними проще делать масштабируемые архитектуры, а не то что они умееют column-less структуры. Для встраиваемых приложений масштабируемость побоку

А какие новые требования появились для встраиваемых/десктопных/мобильных и прочих задач?

Да никаких. Эти задачи просто появились. А РСУБД как не были приспособлены к хранению раснородных данных, структура которых уже описанна в самой записи. БД с данными в xml как были костылем, так и остались. Отчасти в этом виноват сам xml, который слишком идиотичен и поэтому пользовались им исключительно из под палки.

Но теперь появился большой сегмент ВЕБ-приложений, в котором стандарт передачи данных, это JSON и его энергоэффективная форма - BSON. Дело осталось за малым, сделать хранилище, которое будет иметь все преимущества и ограничения JSON. Положить структуру, взять ее обратно, удалить плюс выборка по полям.

Не вижу ничего плохого в концепции РСУБД, в том числе для относительно небольших хранилищ.

Это если задачи подразумевают хранение данных, укладывающихся в реляционную модель без костылей. Если же данные «в свободной форме», то приходится устраивать EAV, что только усложняет запросы и портит производительность. Ну или засовывать всё в xml, лежащий в ячейке. что создаёт трудности для поиска, и вообще костыль.

Вопрос не в фобиях, а в соответствии решения тем требованиям, которые ставит задача.

Речь вообще-то шла о sqlite вообще, а не о каких-то задачах. Так что не надо привлекать ненужные сущности.

Большие или маленькие, это опосредованная характеристика. Гибкость схемы, которую требуют настольные применения, вот что плохо переносит РСУБД.

Не всем настольным применениям нужна гибкость схемы. И уж тем более она далеко не везде критична. А у чётко прописанной схемы есть свои плюсы. Которые тебе должно быть стыдно не знать.

sqlite, это пример образцово выполненного проекта. Написали, отладили, сделали море биндингов и внесли в кучу дистров. На выходе полный вин. Тем не менее, sqlite представляет собой некий недокомпромис. Взяли таблицы и запрросы из РСУБД и выкинули обязательные типы столбцов, как в nosql. Плюсов от этого решения почти нет, а минусы в виде неявных ограничений все на месте.

В популярных nosql вообще структуры в нормальном смысле вообще нет. Можно накидать чего угодно, и надеяться, что это как-то взлетит. Sqlite хоть какой-то каркас предоставляет.

Ну а что до «образцово выполненного проекта», то согласен. Видел где-то пост о том, как sqlite не может поднять дамп своей же базы. Образцово...

Не аргумент. Еще раньше на столах были счеты и для большого класса «настольных» задач это тоже работало...

Здорово. Теперь место счёт торжественно займёт NoSQL.

Mama was queen of the mambo
Papa was king of the Congo
Deep down in a uni
I was bangin' with my mongo

Every schoolboy liked to be
In my place instead of me
Cause I'm the king of mongo, baby
I'm a real NoSQL god

Речь вообще-то шла о sqlite вообще, а не о каких-то задачах. Так что не надо привлекать ненужные сущности.

Во первых, для решения таких задач и придумали sqlite. Во вторых, нет задач, не нужно и решение. Говорить об sqlite в отрыве от запросов просто бессмысленно.

Не всем настольным применениям нужна гибкость схемы. И уж тем более она далеко не везде критична.

Для таких задач давно уже все БД написаны.

А у чётко прописанной схемы есть свои плюсы. Которые тебе должно быть стыдно не знать.

У самой схемы нет никаких преимуществ. Есть задачи, в которых допустима жесткая схема базы данных и такие задачи решаются легче, проще и с меньшим количеством ошибок. И есть задачи, которые не допускают введение такой схемы. Глупо не использовать схему, если она допустима и еще более глупо навязывать ее там, где она не применима.

В популярных nosql вообще структуры в нормальном смысле вообще нет. Можно накидать чего угодно, и надеяться, что это как-то взлетит. Sqlite хоть какой-то каркас предоставляет.

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

И в любом случае можно накидать что угодно. И накидывают же.

Ну а что до «образцово выполненного проекта», то согласен. Видел где-то пост о том, как sqlite не может поднять дамп своей же базы. Образцово...

фигня. Все проблемы sqlite решаются примитивной правкой sql в том же дампе. И их количество на порядки меньше, чем в проектах с такой же пользовательской базой.

Повторюсь, если бы этот проект был бы таким проработанным и распостраненным, как sqlite, то это был бы эпик вин. А так один несчастный биндинг в nodejs...

Если же данные «в свободной форме»

в, практически, любой рдбмс есть блобы для хранения данный в «свободной форме»

приходится устраивать EAV, что только усложняет запросы и портит производительность

если реляционная алгебра усложняет вам жизнь, вам надо менять профессию

> Речь вообще-то шла о sqlite вообще, а не о каких-то задачах. Так что не надо привлекать ненужные сущности.

Во первых, для решения таких задач и придумали sqlite.

Еще раз, «каких именно задач»?

Во вторых, нет задач, не нужно и решение.

Тут не поспоришь. :)

Говорить об sqlite в отрыве от запросов просто бессмысленно.

И каких именно запросов? Можно побольше конкретики?

> Не всем настольным применениям нужна гибкость схемы. И уж тем более она далеко не везде критична.

Для таких задач давно уже все БД написаны.

По такой логике, все эти ваши монги-шмонги тоже не нужны, так как уже всё написано. Причём еще в 60x.

Да нет там никакого каркаса.

Есть. Там хоть таблички есть. Если в табличке есть колонки «url» и «number_of_visits», то очень врядли в первой будут овцы а во второй - корабли.

Все равно приходится оборачивать вызовы в свои обертки, чтобы контролировать поток данных и ошибок. Какой смысл в том, что приложение выдаст непонятный код ошибки и завершится?

Если приложение выдаёт непонятный код ошибки, то это причина выпороть его разработчкиков розгами. И к обёрткам это имеет опосредованное отношение.

А если ошибки репортятся правильно, то в случае реляциоки есть надежда увидеть что-то типа «ой, в колонке 'количество_учеников' лежит не число а строка 'математика', похоже кто-то покоцал базку». В то время как для этих твоих супергибких NoSQL и сформировать-то сообщение будет проблематично, так как прийдётся сравнивать две древовидные структуры данных, а это мягко говоря сложно даже графически отобразить в общем случае.

фигня. Все проблемы sqlite решаются примитивной правкой sql в том же дампе. И их количество на порядки меньше, чем в проектах с такой же пользовательской базой.

Мне даже страшно подумать, каким будет твой код, что пытается править дамп перед восстановлением базы. :) Ну или глянуть на лицо Сашеньки Ивановой из отдела снабжения, которой ты говоришь по телефону «фигня, просто запусти emacs, открой в нём дам и переставь местами 'CREATE TABLE' так, чтобы не было сбоя в зависимостях».

Не удивительно, что тебе так милы эти такие гибкие и хорошие NoSQL базки.

в, практически, любой рдбмс есть блобы для хранения данный в «свободной форме»

Ничего, что это костыли? Особенно если нужен поиск по этим полям.

если реляционная алгебра усложняет вам жизнь, вам надо менять профессию

EAV приводит к проседанию производительности и к извращению структуры базы. В результате, вместо того, чтобы отображать реальные объекты в БД, приходится отображать их поверх выдуманных сущностей. Бесполезная и глупая абстракция.

Очередная попытка пропихнуть json в серьёзную сферу.

Его не надо никуда пропихивать - он давно уже вытеснил сраный XML ото всюду, где мог. ХМЛ остался только в тухлых легаси системах, откуда его не выдерешь без крови.

Неужели кому-то нужны все эти костыли, когда для xml всё давно написано?

Почему костыли? Вполне себе нормальный формат. Стократ лучше ХМЛ и даже несмотря на «давно всё написано», успешно вытесняет уродливые теги.

Вполне себе нормальный формат.

Велосипед. Можно сделать то же самое, только вместо скобочек точечки, звёздочки и запятые и это будет стократ лучше json-а

успешно вытесняет уродливые теги.

Уродливые квадратные скобочки вытесняют уродливые треугольные? Это однозначный прогресс!

Еще раз, «каких именно задач»?

хранения данных приложения.

И каких именно запросов? Можно побольше конкретики?

Есть структура данных. Сохранить ее в базу, найти ее в базе, взять из базы и удалить из базы.

По такой логике, все эти ваши монги-шмонги тоже не нужны, так как уже всё написано. Причём еще в 60x.

Вот монги-шмонги в 60-х не было. А sql закончил свое развитие еще в прошлом веке.

Если приложение выдаёт непонятный код ошибки, то это причина выпороть его разработчкиков розгами. И к обёрткам это имеет опосредованное отношение.

Чтобы ошибка была понятной, надо поймать ее в приложении и наполнить контекстом. Типа при сохрпнении структуры «ученик» в поле возраст оказалась строка вместо числа. Поле пришло оттуда-то и кнопки исправления ситуации. Это и есть обертка.

А не error 312 data type unknown и одна кнопка «terminate application»

Есть. Там хоть таблички есть. Если в табличке есть колонки «url» и «number_of_visits», то очень врядли в первой будут овцы а во второй - корабли.

а теперь прикинь, что как раз надо, чтобы в коллекции кораблей подряд шли записи, едн в поле «трюм» то корабли, то овцы, а в пассажирском корабле вообще трюма нет, зато есть «пассажирский салон», а в танкере «банка с литрами»

Естественно, что в каждом объекте есть тип «пассажирский», «грузовой» или «танкер» и надо искать «танкер» и «литры» или пассажрский и пассажиры или «грузовой» и «трюм»?

В то время как для этих твоих супергибких NoSQL и сформировать-то сообщение будет проблематично, так как прийдётся сравнивать две древовидные структуры данных, а это мягко говоря сложно даже графически отобразить в общем случае.

не нужно. Ошибка «В объекте „класс“ поле „количество учеников“ не число.» Точка.

Мне даже страшно подумать, каким будет твой код, что пытается править дамп перед восстановлением базы. :) Ну или глянуть на лицо Сашеньки Ивановой из отдела снабжения, которой ты говоришь по телефону «фигня, просто запусти emacs, открой в нём дам и переставь местами 'CREATE TABLE' так, чтобы не было сбоя в зависимостях».

Одно из двух. Или ты корабль из спичек строгаешь, или написал неправильную программу, раз она требует от пользователя загрузки дампа да еще и средствами sqlite3.

Впрочем, это одно и тоже.

Ой, как много эмоций.

По сути имеем следующее - и xml, и json предназначены для хранения структурированных данных в тех случаях, когда структура этих данных в общем случае может быть любой. Популярность json по факту связана только с популярностью джаваскрипта.

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

А не error 312 data type unknown и одна кнопка «terminate application»

Не надо врать, это не красиво.

Как раз с реляционками проблем меньше. Там всё ясно - «в колонке 'цена' записано не число а 'селедка'» говорит о том, что кто-то пользовался sqlite а не нормальной РСУБД с правильной поддержкой типов. А так - всё работает как часы.

Что до монго и сотоварищи, было бы интересно глянуть на то, как _ваш_ софт грамотно среагирует на то, что вместо

{ «animal» : «bear»
, «color» : «brown»
}

он вдруг получил

{ «city» : «Paris»
, «country» : «France»
}

Подозреваю, что либо сдохнет, либо решит что речь идёт о звере Париж французского цвета, либо скажет «Ой йо...» и всё равно подохнет.

В любом случае я не верю, что он сможет сколь-нибудь толково объяснить суть проблемы, т.к. проблема сравнения древовидных структур значительно сложнее простой проверки удовлетворения данных какому-то примитивному предикату.

Как раз с реляционками проблем меньше. Там всё ясно - «в колонке 'цена' записано не число а 'селедка'» говорит о том, что кто-то пользовался sqlite а не нормальной РСУБД с правильной поддержкой типов. А так - всё работает как часы.

да как бы не так. В лучшем случае будет что-то такое:

http://community.bamboosolutions.com/cfs-filesystemfile.ashx/__key/CommunityS...

А то и вообще: http://our.umbraco.org/media/upload/12eb3c5f-dbc1-4770-984e-ef70883afbab/ga-s...

Что до монго и сотоварищи, было бы интересно глянуть на то, как _ваш_ софт грамотно среагирует на то, что вместо

{ «animal» : «bear» , «color» : «brown» }

он вдруг получил

{ «city» : «Paris» , «country» : «France» }

Подозреваю, что либо сдохнет, либо решит что речь идёт о звере Париж французского цвета, либо скажет «Ой йо...» и всё равно подохнет.

Да элемнтарно же. Я даже не говорю, что в коллекции, которая предполагает разные типы объекта должно быть стандартное поле «тип» и коллекция должна выглядеть как

{ «type» : «animal», «animal» : «bear» , «color» : «brown» }

он вдруг получил

{ «type»:«city», «city» : «Paris» , «country» : «France» }

Но для понимания ситуации и этого не надо. Достаточно выдать «В объекте нет поля „animal“, а в режиме дебага сдампить полученый json.»

и все.

И таки ситуация, когда онлайновый сервис (суть таже БД) или база данных возвращает вместо ожидаемой структуры нечно совсем другое типа «error»:«404 not found» или null простаки массовая.

Так что умение валидировать ответ и не сильно надеятся на других очень полезно в наше время...