nosql бд со ссылками

Насколько мне известно - никакие. Это же документарные базы, а не реляционные.

Если брать CouchDB, то нужный функционал реализуется следующим образом: а) запрашиваешь документ, б) выделяешь ключики-ссылки, в) запрашиваешь документы (одним запросом), в) разбираешься с результатами, г) ???, д)PROFIT!!

Можно завести вьюшку в которой будут храниться ссылки, но в данном случае это нецелесообразно.

С сылочной целостностью сложнее. Документы из CouchDB не удаляются. Это плюс. Но тогда помимо ссылки нужно хранить еще и ревизию. Это минус. Механизм update'ов позволяет поддерживать некое подобие ссылочной целостности при обновлении. Но тоже с ограничениями.

CouchDB - это вообще база типа ключ-значение, только очень хорошо скрывается. MongoDB, ИМХО, тоже. CouchBase (полукоммерческий проект создателя CouchDB) так вообще и не скрывается даже, но она еще не достигла «продуктового» качества.

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

какие документные базки умеют делать связи между документами (например, поля-ссылки)

MongoDB

В реляционных у нас получается object-relational mismatch, приходится использовать ORM и загаживать базу кучей негуманоидных структур. Это стандарт, но это отвратительно.

С этим надо что-то делать. Но хочется делать оптимально. Чтобы база не превратилась в свалку старых ревизий, чтобы не взорвалась от хранения документов с большим количеством полей (или с широкой/глубокой структурой) итп

Можно намутить простенькую схемку в для OR, а основной массив данных сериализовать в блоб, и легкий gc по надобности. Или, по другую сторону баррикады, нафигачить умный сборщик мусора для key-value.

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

в базке

да ты охуел, братюнь

Просто скоро «документо-ориентированные» БД разовьются до полноценных OODB, причём это преподнесут как прорыв и новое слово в базостроении.

Чтобы база не превратилась в свалку старых ревизий

У тебя документы настолько часто меняются?

Лично для меня, наличие множества ревизий - это плюс. Да и с технической точки зрения это тоже плюс: файлики с данными только дописываются, что позитивно влияет на надежность.

Кстати, в серьезных системах... Даже в 1С документы не удаляются. А в серьезныхЪ системахЪ (tm) они не удаляются принципиально (без вмешательства в БД).

В реляционных у нас получается object-relational mismatch

Хочу напомнить, что в РБД пресловутый mismatch как раз и происходит из-за их реляционной природы. ;) А ты от нее избавляться не хочешь...

Хренушки, придется данные денормализовывать.

Несколько запросов к БД это совсем не зло. Это в мире РБД - это зло, только все на это клали вообще-то.

Да и к Key-Value базами все не так просто. Задача KV баз не в том, чтобы мы свою предметную область разбивали на миллиарды ключей и значений. Как раз наоборот: в одной «таблице» храним первичный ключ (может быть и составной) и некую структуру данных (наш документ). В других «таблицах» храним индексы.

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

до полноценных OODB,

А они в природе существуют? Хочу пруфлинков!

MongoDB. Но она гарантированно навернется при сбое при записи. ACID только у Couch, но она ссылок не умеет.

ACID только у Couch, но она ссылок не умеет.

Да, в MongoDB можно разрешать ссылки на стороне сервера, но делается это исключительно вручную. И опять же, без какого-либо контроля целостности. Причем, в MongoDB эта операция нихрена не атомарна. Она и в CouchDB тоже не атомарна, но там на это пофиг, ибо ревизии.

А вообще, ждать CouchBase 2.0 :)

В CouchDB нету ссылок, но ты можешь заставить выгружать документы по ссылке при вызове view.

Типа в юзере есть ссылка на группу, но вьюшка, которая эмиттит только юзеров - может быть вызвана с include_docs и в doc будут документы соответствующих групп. Что б не делать потом второй запрос.

http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views#Linked_documents

документы по ссылке при вызове view.

Неприменимо для reduce'нутых вьюшек. И опять же, без гарантий атомарности.

Неприменимо для reduce'нутых вьюшек.

Ну извините

И опять же, без гарантий атомарности.

Против CAP-теоремы вообще сложно переть :)

Против CAP-теоремы вообще сложно переть :)

А зачем же переть, когда и обойти можно?