LINUX.ORG.RU

Вторая волна разработки Java-приложений: Базы данных типа NoSQL

 ,


0

3

Системы управления базами данных, не использующие SQL (или NoSQL-СУБД), постепенно выходят на первый план в эру Web 2.0, поскольку они эффективно решают проблемы масштабируемости. Несмотря на то, что эти СУБД еще находятся на заре своей популярности, они уже используются такими крупными компаниями, как Google и Facebook. Базы данных, не имеющие схем, кардинально отличаются от традиционных реляционных БД, однако работа с ними на практике оказывается проще, чем кажется, особенно если проектирование начинать с разработки модели предметной области, а не реляционной схемы.

>>> Подробности

Ответ на: Кодд от mumpster

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

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

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


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

r ★★★★★ ()
Ответ на: комментарий от rtvd

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

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

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


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

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

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

r ★★★★★ ()
Ответ на: комментарий от r

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

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

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

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

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

rtvd ★★★★★ ()
Ответ на: комментарий от JFreeM

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

InvalidDirectionException

rtvd ★★★★★ ()
Ответ на: комментарий от rtvd

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

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

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


Удобную.

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


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

r ★★★★★ ()
Ответ на: комментарий от r

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

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

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

rtvd ★★★★★ ()
Ответ на: комментарий от rtvd

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

r ★★★★★ ()
Ответ на: комментарий от r

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

MUMPS

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

mumpster ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.