-
Анонимно0
0
Вопрос не про Django, вопрос концептуальный. Просто здесь тусуются умные люди и лучшего места для вопроса я не нашел, извините.
Значит, как обычно для правильного использования новой концепции необходимо произвести сдвиг парадигмы, т.е я не могу сейчас мыслить в терминах документ-ориентированных хранлишь, все сводится к аналогиям с RDBMS.
Есть задачи, где RDBMS мало применимы, точнее их с успехом можно заменить такой модной на сегодня технологией. Но как-то в голову не укладывается.
1. Пример задач из реальной жизни, где хорошо применимы документ-ориентированные базы (Blog, Twitter, Bug Tracker, Digg,...?!?)
2. Например мы хотим сделать блог, я так понимаю, что каждая страница блога (сама запись и коментарии) — будут документом. Т.е. мы сможем делать выборку по документу одним запросом. Здесь все удобно и ясно, но допустим у нас есть страница пользователя, где он может увидеть все свои коментарии. А коментарии у нас храняться в записях блога. Получается, что будут очень большие накладные расходы при такой выборке, либо придется делать еще один документ, который будет хранить страницу пользователя, тогда при сохранении коментария, нам надо будет продублировать его в записи блога и в документе пользователя. Это так? Я знаю, что там тоже есть некое подобие ForeignKey, но это как бы убивает всю прелесть. Кажеться логичным, что б мы могли не порождать лишних сущностей (дублирование коментария на двух страницах), а коментарий и там и там был бы одним "объектом". Такое есть в CouchDB, Mongo? Или все же информация будет дважды записана?
http://softwaremaniacs.org/blog/2007/09/26/couchdb/ — читал, так что не отсылайте. -
- Пример задач из реальной жизни, где хорошо применимы документ-ориентированные базы (Blog, Twitter, Bug Tracker, Digg,...?!?)
Я не могу представить себе примера, где бы документоориентированные хранилища применялись бы плохо. Поэтому всё вышеперечисленное и всё остальное — хорошие примеры :-).
тогда при сохранении коментария, нам надо будет продублировать его в записи блога и в документе пользователя. Это так?
Да, так. Суть обычно сводится к тому, что вы при добавлении данных распихиваете их во все места и виды, в которых они потом понадобятся.
Другое дело, что конкретный вид модели вам никак не навзяывается. Можно хранить все тела комментариев с пользователем, можно хранить только IDшки. В последнем случае при отображении страницы пользователей там будет выводиться, например, 20 комментариев, которые надо будет вытащить 20-ю точечными запросами. Кажется, в таких хранилищах это достаточно быстро.
Кажеться логичным, что б мы могли не порождать лишних сущностей (дублирование коментария на двух страницах)
Это кажется логичным только с точки зрения нормализации реляционной СУБД. Хранение исходных данных один раз направлено на экономию размера, но главное — на предотвращение ситуаций, когда пользователь БД обновит одну часть данных, но забудет обновить другую.
У документарных систем выбраны другие параметры оптимизации. Для достижения максимальной скорости чтения данные естественным образом дублируются (денормализуются), без этого нельзя. Поэтому здесь это не только логично, в этом вся суть идеи :-). А корректность дублированных данных обеспечивается заданными алгоритмами пересчёта. В CouchDB они задаются кодом, лежащим прямо в хранилище. А в такой простецкой штуке, как Redis, например, всё пересчитывается кодом веб-приложения, которое её использует. Это ставит ограничение на то, что такое приложение должно быть единственным клиентом БД, но это так всегда и есть.
-
Анонимно0
0
Спасибо Иван, буду вникать.
Мало по русски хороших статей на эту тему (в основном все ограничиваются тем, что это круто + тривиальный пример, без интересных пояснений), на английском конечно много, но несколько сложно ориентироваться в незнакомой теме.
Вот кстати нашел статью с пояснениями двух способов хранения постов и коментариев в блоге на CouchDB: http://www.cmlenz.net/archives/2007/10/couchdb-joins
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.