Здравствуйте!

Для чего нужен dbref в mongoenigne ?


И как правильней будет, с ним или без него ?)

dbref - Это тип из bson (pymongo), содержит имя коллекции + идентификатор

с mongoenigne не знаком, но могу предположить что без dbref, ссылки будут хранится в виде ObjectId - только идентификатор,
с dbref=True, будут хранится в виде DBRef, т.е. + имя коллекции.

без dbref можно работать если вы точно знаете в какой коллекции лежит документ, если это не фиксируется, либо возможные документы могут лежать в разных коллекциях, то необходимо dbref.

так же можно обойтись без dbref если все данные лежат в одной коллекции (но это не желательно для больших проектов)

Я уточню.
Нужно обходится без DBRef, если это позволяет система.
Предпочтительный и рекомендуемой способ для большинства систем - ручные ссылки на _id, получаемый перед началом операции с помощью ObjectId().

Lexander
Предпочтительный и рекомендуемой способ для большинства систем - ручные ссылки на _id, получаемый перед началом операции с помощью ObjectId().

в смысле вручную генерировать _id? почему он предпочтительный?

А он и так всегда вручную генерируется.
Некоторые библиотеки просто неявно вызывают ObjectId(), но смысл от этого не меняется.
Так написано в официальной документации.
Возможно, как-то связано с внутренними алгоритмами.

ЗЫ
Кроме указанного вами случая разных коллекций.

o7412369815963
в смысле вручную генерировать _id? почему он предпочтительный?

я подумал про идентификаторы вида: 1,2,3,'A','B','X',…

Lexander
Так написано в официальной документации.

Согласен с документацией, тут может быть плюс в том что идентификатор может создаваться не тем процессом который записывает документ, или вообще документ не будет записан.
Например клиент создал идентификатор и отправил серверу указ выполнить обработку и сохранить по указаному идентификатору не дожидаясь ответа. В случае автоинкрементного (например в mysql) нужно было-б дождаться ответа с идентификатором, хотя можно реализовать вариант как с objectid, но я не видел что-б кто-то так делал в *sql, а в mongodb это основной вариант.

o7412369815963
я подумал про идентификаторы вида: 1,2,3,'A','B','X',…

Самое интересное, что так тоже можно делать. :)
В смысле есть возможность.
Вопрос смысла и необходимости.

Например, если нужно сделать специфические правила шардинга, обусловленные бизнес-логикой, и сам шардинг настроен по _id.

Lexander
Самое интересное, что так тоже можно делать. :)

Я кстати тестировал скорость чтения на mongodb 1.6, нумератор (1,2,3…) vs objectID для _id. Дак с ObjectId почему то было быстрее на 20-30%.

Интересное поведение.
Как думаете, почему?

хз, может простые типы нужно было подготавливать перед помещением/поиском в индекс, например в хеш переводить. а ObjectID работает как есть.
считаю что сейчас это уже не актуально и нужно заново тестировать, т.к. монга сильно продвинулась.