Поиск:

Ответ в темуСоздание новой темы Создание опроса
> MongoDB. Впечатления? MongoDB  
:(
    Опции темы
lukas
Дата 23.7.2011, 23:35 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 771
Регистрация: 23.2.2007

Репутация: нет
Всего: 15



Цитата(Бонифаций @  13.8.2010,  04:14 Найти цитируемый пост)
Skynin,  Это конечно круто, но что делать, например с много <-> много отношениями? как их в nosql загнать?

Например врачи - пациенты. Один врач может лечить кучу пациентов, каждый пациент может лечиться у нескольких врачей.

В случае реляционной модели - все ясно. Как это будет в mongodb?


Решил реанимировать тему.
И ответить на вопрос, была похожая просто ситуация. 

А что именно не так? Такой же случай как и с комментариями. У комментария есть свойство ELEMENT_ID к которому он пренадлежит.

Также и у пациента есть его врач, Но допустим если врачей несколько есть масса вариантов. 

1. Не забывайте что mongo это иерархическая база данных, и  она очень хорошо работает с иерархиями. Поэтому у врача может храниться список ID-ников его пациентов. Но это становится накладно, есть пациентов очень много. Если их еще менее 1000 то годится.

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

3. Дополнительная таблица для множественных связок, классика.


Думаю еще можно совместить 2 варианта, т.е. хранить и там и там - для оптимизации разных запросов. Чтобы запросить всех пациентов врача нужно будет всего лишь 2 запроса и без всяких join'ов.  

Это сообщение отредактировал(а) lukas - 23.7.2011, 23:37


--------------------
http://code.google.com/p/orionphp/ - opensource скриптовой язык Orion (аналог PHP) для freepascal/delphi.
PM MAIL WWW   Вверх
tishaishii
Дата 13.10.2011, 06:51 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Создатель
***


Профиль
Группа: Завсегдатай
Сообщений: 1262
Регистрация: 14.2.2006
Где: Москва

Репутация: нет
Всего: 8



Не стоит отрицать полностью старый подход в построении БД. Оставить наиболее эффективные и полезные возможности или весь функционал, по возможности. Имею в виду реляционную модель.
Универсальной модели для любой задачи, по-моему, быть не может. Поэтому, модели можно совмещать или подбирать для каждой задачи свои инструменты, которые бы позволяли решить задачу самым простым, надёжным и понятным всем способом.

Это сообщение отредактировал(а) tishaishii - 13.10.2011, 06:51
PM MAIL ICQ Skype   Вверх
kshvakov
Дата 26.10.2011, 22:36 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 1
Регистрация: 24.2.2011

Репутация: нет
Всего: нет



PM MAIL   Вверх
bl1zzarrd
Дата 2.12.2013, 20:57 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 15
Регистрация: 3.10.2013

Репутация: нет
Всего: нет



Есть коллекция пациент, который содержит основную информацию о каждом человеке и отображает человека к patient_id, и коллекция записей, который содержит один документ для каждого теста или процедуры. Один пациент может иметь десятки или даже сотни документов в коллекции записей.
PM MAIL   Вверх
Ответ в темуСоздание новой темы Создание опроса
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | NoSQL | Следующая тема »


 




[ Время генерации скрипта: 0.1053 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.