|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Добрый день. Стартую новый небольшой проект и есть желание реализовать хранение и обработку данных через NoSQL (mongoDB). С технической точки зрения все понятно, туториалы изучены, примеры написаны. А вот как организовать правильное хранение данных не ясно. Суть в следующем: есть несколько объектов (проекты), они состоят из этапов, а они из задач и так далее. Я не могу понять все мне хранить в одной коллекции - проекты? Тогда у меня будет выюираться оочень большой пласт данных с каждым запросом. Или хранить в разных колекциях ссылаясь на идентификаторы, но тогда получаем туже реляционную бд, только вид с боку? Коллеги поделитесь опытом! Заранее большое спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 20:36 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
вопрос в том, зачем тебе нужно выбрать nosql? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 21:59 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Это экспиримент - в целях получения опыта работы с NOSQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 23:01 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Тогда задача должна быть соответствующей NoSQL подходу ... |
|||
:
Нравится:
Не нравится:
|
|||
09.01.2012, 23:59 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Она и соответствует :) Незнаю поможет-ли, это описание к НОдеЙС драйверу, реализация простого Блога, в одном случае используютсы комменты вложенные в пост во втором в разных коллекциях http://alexeypetrushin.github.com/mongo-model/composite.html http://alexeypetrushin.github.com/mongo-model/associations.html Ответ на ваш вопрос зависит от числа задач и комментов а также от запросов, на первый взгляд я бы разбил на поекты->задачи(со вложенными комментами). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2012, 02:29 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
private, Спасибо! Я так и поступил, отдельная коллекция для Project, отдельныя для Task. Например Project содержит в себе все данные о проекте, запросы на изменения, реестр рисков и мероприятия по ним, данные бюджета и список участников проекта. Получается многовато, но эта инфа загружается один раз в начале работы и хранится на клиенте до завершения его работы. Зато не приходится постоянно дергать сервис и сервер Mongo. Тоже самое касается задач - они имеют ссылку на этап проекта, содержат историю их "движения" между исполнителями, содержат прикладываемые документы и т.д. Исполнителю всегда загружается только список задач на которых он сейчас ответственный. Если надо получить список всех задач (например менеджеру или тим лиду) - то загружается информация только по задаче без вложенных вещей - Task.Brief, Task.Description ......, Далее при подробном просмотре вся остальная инфа. Надеюсь комунибудь пригодится мой опыт! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2012, 11:04 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Аналогичная проблема. Читаю доки по mongodb, там пишут: http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-EmbeddingandLinking Generally, for "contains" relationships between entities, embedding should be be chosen. Use linking when not using linking would result in duplication of data. Проблема в том, что не могу понять, какие объекты считать объектами с "contains" relationship содержимым. Допустим, что у меня есть что-то вроде системы для тестирования людей. Имеем объекты Вопрос, Тест. Тест, естественно, содержит список вопросов. Так вот эти вопросы, являются частью теста, соответственно видим тот самый "contains" relationship . Однако копирование содержимого вопросов в Тест влечет за собой дублирование данных, о чем в документации тоже сказано. Собственно, я в замешательстве. Прошу пролить свет на проблему. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.02.2012, 16:17 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
проблемы никакой нет, все зависит от необходимых выборок. В случае с тестом и вопросами выборка идет последовательно - вначале отображаем список тестов из таблицы tests, потом список вопросов из таблицы questions по ключу test_id. Вот если бы понадобилось одновременно и то, и другое, то нужно было бы уже взвешивать решения ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2012, 00:36 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
А вот интересно, можно загрузить заепись из коллекции, но без встроенных объектов? Или загружать их выборочно В документации я такого не нашел. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2012, 05:44 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Вопрос снят. Нашел такую штуку. Код: javascript 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.03.2012, 05:45 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Код: sql 1.
А с чего вы взяли, что NoSQL = No related ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2012, 18:59 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Hett Код: sql 1.
А с чего вы взяли, что NoSQL = No related ? Вопрсоом на вопрос: как в mongo можно делать отношенияи работать с ними? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2012, 14:35 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
А что мешает создать 2 коллекции и в одной сослаться на другую? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2012, 15:19 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
Все же понятие реляционности, как оказалось, оказалось за рамками: авторСУБД управляет наборами JSON-подобных документов, хранимых в двоичном виде в формате BSON. Хранение и поиск файлов в MongoDB происходит благодаря вызовам протокола GridFS. Подобно другим документо-ориентированным СУБД (CouchDB и др.), MongoDB не является реляционной СУБД. Среди других отличий от традиционных реляционных СУБД: 1. Отсутствует оператор «join». Обычно данные могут быть организованы более денормализованным способом, но на разработчиков ложится дополнительная нагрузка по обеспечению непротиворечивости данных. 2. Нет такого понятия, как «транзакция». Атомарность гарантируется только на уровне целого документа, т.е. частичное обновление документа произойти не может. 3. Отсутствует понятие «изоляции». Любые данные, которые считываются одним клиентом, могут параллельно изменяться другим клиентом[3]. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2012, 21:07 |
|
MongoDB, структура данных
|
|||
---|---|---|---|
#18+
HettВсе же понятие реляционности, как оказалось, оказалось за рамками: авторСУБД управляет наборами JSON-подобных документов, хранимых в двоичном виде в формате BSON. Хранение и поиск файлов в MongoDB происходит благодаря вызовам протокола GridFS. Подобно другим документо-ориентированным СУБД (CouchDB и др.), MongoDB не является реляционной СУБД. Среди других отличий от традиционных реляционных СУБД: 1. Отсутствует оператор «join». Обычно данные могут быть организованы более денормализованным способом, но на разработчиков ложится дополнительная нагрузка по обеспечению непротиворечивости данных. 2. Нет такого понятия, как «транзакция». Атомарность гарантируется только на уровне целого документа, т.е. частичное обновление документа произойти не может. 3. Отсутствует понятие «изоляции». Любые данные, которые считываются одним клиентом, могут параллельно изменяться другим клиентом[3]. дык.... в том то и вопрос.... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2012, 14:45 |
|
|
Start [/forum/topic.php?fid=48&msg=37859364&tid=1856977]: |
0ms |
get settings: |
16ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
80ms |
get topic data: |
4ms |
get forum data: |
1ms |
get page messages: |
390ms |
get tp. blocked users: |
1ms |
others: | 153ms |
total: | 652ms |
0 / 0 |