MongoDB: posts + users

[Absinthe]

Изучаю монго.
Задача: Есть посты. Внутри каменты. И у постов и у каментов есть пользователи, которые их написали.

Каменты содержатся внутри постов. Как хранить пользователей? Понятно же, что не объектами внутри постов и каментов. Значит отдельная "таблица" и userId.
И как потом достать пост, чтобы достались связанные с постом и каментами пользователи?

 

[Splurov]

http://www.mongodb.org/display/DOCS/Schema+Design
http://www.mongodb.org/display/DOCS/Database+References

 

[Absinthe]

Спасибо, тогда новый вопрос:

<?php

$m = new Mongo();
$db = $m->selectDB('test');

$db->users->remove();
$db->posts->remove();

$user1 = array('_id' => 1, 'name' => 'User1');
$user2 = array('_id' => 2, 'name' => 'User2');
$post1 = array('text' => 'Text 1', 'user' => MongoDBRef::create('users', 1));
$post2 = array('text' => 'Text 2', 'user' => MongoDBRef::create('users', 2));

$db->users->save($user1);
$db->users->save($user2);
$db->posts->save($post1);
$db->posts->save($post2);

foreach ($db->posts->find() as $post) {
    $post['user'] = $db->getDBRef($post['user']);
    var_dump($post);
}

Допустим у меня 100 постов на странице. Это оно что, 100 запросов к базе будет делать? Я прав?
Как нибудь на момент загрузки можно связанные элементы указать, чтобы они сразу в запрошенном документе вернулись?

 

[zerkms]

Чтобы связанные элементы сразу загружались - нужно использовать реляционные БД. А если уж смотрите в сторону документо-ориентированных, то и храните данные соответственно.

 

[tz-lom]

Да ладно,нормально хранится
да, 100 запросов, но всё таки запрос на монгу это не запрос на MySQL , это не так страшно
если хочется настоящей скорости - денормализуйте данные , поддерживать их в актуальном состоянии в монге - не проблема

 

[Absinthe]

Чтобы связанные элементы сразу загружались - нужно использовать реляционные БД

Логично. Но я думал что тут оно будет, хоть и неприоритетное.

то и храните данные соответственно.

Как предложено ниже?

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

Т.е. при изменении аватара пользователя мне надо апдейтить все посты от него, все каменты от него, всю личную переписку, данные френдов и т.д.? Говнокодом не сильно будет пахнуть?

 

[tz-lom]

ну,если с умом подойти , то нет
на кой вам в отображении комментария переписка пользователя? вам нужно его ID (а он уже есть) , имя,может ящик или что там у вас выводится,ссылка на аватарку,если очень хочется (лично я предпочитаю просто кидать на сервак аватарку в виде файла,давая ему такое имя которое можно однозначно сопоставить с пользователем)

 

[Absinthe]

на кой вам в отображении комментария переписка пользователя?

Я просто перечислил случаи, где используется аватарка пользователя. Ну или его пол, например(рядом с ником чтобы писать).

лично я предпочитаю просто кидать на сервак аватарку в виде файла,давая ему такое имя которое можно однозначно сопоставить с пользователем

А расширение файла?

Вот допустим мне нужно [что-то] пользователя отображать в 4 разных местах. Т.е. при изменении этого [что-то] мне надо по куче коллекций его апдейтить?

 

[tz-lom]

А расширение файла?

.png

Вот допустим мне нужно [что-то] пользователя отображать в 4 разных местах. Т.е. при изменении этого [что-то] мне надо по куче коллекций его апдейтить?

да , но при редких изменениях и частых чтениях это окупается

 

[Absinthe]

.png

С 10 до 40кб на картинку уже размер увеличится. С одной стороны не много, а с другой стороны загрузка будет дольше, клиенту неудобнее.

да , но при редких изменениях и частых чтениях это окупается

ужас

 

[tz-lom]

С 10 до 40кб на картинку уже размер увеличится. С одной стороны не много, а с другой стороны загрузка будет дольше, клиенту неудобнее.

спорный вопрос,вы наверное не умеете его готовить
на самом деле всё равно же юзерпик генерится из залитой им картинки,и приводится к какому-то формату, я не видел ни одного места где бы производилась вариация форматов и оценивалось качество/размер

 

[Absinthe]

tz-lom понятное дело, что без потери качества можно перевести лишь в png.
Однако если исходный рисунок в jpg, то можно взять и его(ну и поменять размер в случае, если не подходит). Файо меньше будет.
Хотя да, это было актуально года 2-3 назад, сейчас уже разницу в 200кб на страницу заметить сложно.

 

[tz-lom]

tz-lom понятное дело, что без потери качества можно перевести лишь в png.
Однако если исходный рисунок в jpg, то можно взять и его(ну и поменять размер в случае, если не подходит). Файо меньше будет.
Хотя да, это было актуально года 2-3 назад, сейчас уже разницу в 200кб на страницу заметить сложно.

на вкус и цвет все фломастеры разные,не суть что вы выберете,суть в том что что то одно

 

[Absinthe]

Я тут немного почитал...
А почему бы не воспользоваться классическим способом?
http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-$in

Сначала спросить посты, взять id авторов.
Потом спросить авторов { "_id" : { $in : usersIds } } и вставить в посты.

Будет 2 запроса без всякой денормализации и, соответственно, без лишних запросов на изменение связанных данных..