>ну, например, ACID

Никакого отношения к кодду не имеет.

в не РСУБД есть кое-какие трудности с обеспечением

Нету там никаких трудностей.

>А как отношение M:N моделируется в NoSQL?

Учитывая что NoSQL это не стандарт...:) А вообще это можно реализовать даже в реляционной модели - стоит добавить тип «список значений». Почему этого никто до сих пор не сделал - за гранью моего понимания.

А есть ли где такое?

Вот хороший вопрос - 21 век на дворе уже бы могли изобразить что-то типа

....
fk list int references ref_table(pk)
....

Ведь очевиджно же что «понимая» на уровне DDL такую фигню как M:N - можно писать более оптимальныё индексы, чем на joinы по трем таблицам.

>>А как отношение M:N моделируется в NoSQL?

Учитывая что NoSQL это не стандарт...:)

Конечно не стандарт. Интересует то, как это можно нормально смоделировать хоть в одной из NoSQL баз.

А вообще это можно реализовать даже в реляционной модели - стоит добавить тип «список значений». Почему этого никто до сих пор не сделал - за гранью моего понимания.

Тогда отношение M:N будет храниться как часть описания одной из сторон. Это сделать можно без проблем, т.к. некоторые базки поддерживают массивы. Но тогда возникают вопросы: 1) какую из сторон выбрать в качестве хранилища отношения. 2) как проводить эффективный поиск с _обеих_ сторон, а не только той, что хранит в себе M:N отношение.

в жопу они катятся, эти ваши noSQL решения. Говнище распоследнее.

> в жопу они катятся, эти ваши noSQL решения. Говнище распоследнее.

InvalidDirectionException

> Это сделать можно без проблем, т.к. некоторые базки поддерживают массивы.

И на эти массивы можно references?

1) какую из сторон выбрать в качестве хранилища отношения.

Удобную.

2) как проводить эффективный поиск с _обеих_ сторон, а не только той, что хранит в себе M:N отношение.

Аналогично 1:N.

>>2) как проводить эффективный поиск с _обеих_ сторон, а не только той, что хранит в себе M:N отношение.

Аналогично 1:N.

Не понял. Вот есть кучка записей А и кучка записей Б. Между ними - отношение M:N, причем оно хранится как список указателей на Б у каждого элемента А. Как мне выяснить, какие элементы А ссылаются на некий элемент Б? Делать поиск по всем А и рыться в их ссылках на Б?

Разница между 1:N и N:M тольков том один FK в B или массив FK.

.... fk list int references ref_table(pk) ....

Ведь очевиджно же что «понимая» на уровне DDL такую фигню как M:N - можно писать более оптимальныё индексы, чем на joinы по трем таблицам.

ИнформИКС, своя объектная модель поверх Cache

таких моделей данных поверх каше есть больше одной вместо join-ов — индексы по навигации

СУБД “ИНФОРМ ИКС”

Выше уже упоминалось о том, что мы реализовали собственную модель данных и СУБД на платформе Сасhе'. Она представляет собой высокоуровневую надстройку в Сасhе', поддерживающую объектную модель данных (ОМД) в сочетании с традиционными для Сасhе' средствами, что обеспечивает высокую скорость создания прикладных систем и их высокое качество.

ОМД реализует как явные связи между объектами, так и связи по ссылкам. И тем и другим связям приписывается определенная семантика в обоих направлениях. Явные связи обеспечивают естественную поддержку отношения “многие-ко-многим” между объектами (в реляционной модели для организации связи “многие-ко-многим” необходимо создавать дополнительную таблицу, что нарушает естественные отношения предметной области). Между двумя объектами можно объявить несколько связей. Поддерживается связь объекта самого с собой.

Семантика связей явно отражается в объектных Навигаторе и Генераторе отчетов, которые входят в состав “Информ Икс”.

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

http://www.informx.ru/st8.htm
http://www.informx.ru/st1.htm

MUMPS

гыыы, как бы и IBM не засудило за «сходное до степени смешения название»:-)
у тех есть Informix, в некторых АТС (типа искрателя си-2000) до сих пор применяется.
а кэш родом из mumps как раз. ещё раз повторюсь -везде есть свои тараканы.