проверьте что ваш драйвер в принципе в это умеет, а если умеет что это не требует какой-то особой конфигурации

а что там проверять, конечно умеет. Node драйвер нативный

какие 30 раз мне мало. вы вообще со мной разговариваете?

Нужен совет по поводу названия полей. Допустим есть коллекция Users Users { id: Number, name: String, ..., ..., comments: [ { id: Number, text: String } ] } И коллекция комментариев Comments Comments { id: Number, text: String, likes: Number, date: Date, ... ... } Вопрос: как лучше называть id комментариев в массиве comments коллекции Users? comment, comment_id, commentId, просто id? Имеет ли смысл id в коллекциях называть в соответствии с таблицей, как userId, commentId ?

Нужен совет по поводу названия полей. Допустим есть коллекция Users Users { id: Number, name: String, ..., ..., comments: [ { id: Number, text: String } ] } И коллекция комментариев Comments Comments { id: Number, text: String, likes: Number, date: Date, ... ... } Вопрос: как лучше называть id комментариев в массиве comments коллекции Users? comment, comment_id, commentId, просто id? Имеет ли смысл id в коллекциях называть в соответствии с таблицей, как userId, commentId ?

Почему не ориентДБ для этого использовать?

Потому что вопрос был не про выбор базы данных, а про именование полей. Хранить комментарии в графом хранилище не имеет никакого смысла

Хранить комментарии в монге тоже

День добрый, может кто знает зачем в java mongodb driver два вида документов BsonDocument и Document, при этом insertOne принимает ТОЛЬКО Document?

https://jira.mongodb.org/browse/JAVA-2708

Спасибо большое. Стало немного яснее. А этот BsonDocument никак не за insert`ить?

Комментарии можно хранить в любом хранилище, которое позволяет искать по префиксу, так как связи между комментариями, в самом сложном случае будут представлять из себя дерево. А значит matherialized path полностью закроет все потребности. В монге из можно хранить как минимум тремя способам https://docs.mongodb.com/ecosystem/use-cases/storing-comments/ Использовать графовые хранилища за пределами задач которые решаются с помощью теории графов будет как минимум крайне неэффективно и сложно. Во-первых из-за специфичности архитектур, которые заточены под хранение и выборку по большим количествам рёбер. Во-вторых, из-за полного бардака с языками запросов, которые опять-же заточены под работу со слабоиерархичными данными.

что делать при "file:WiredTiger.wt, connection: __wt_turtle_read, 336: WiredTiger.turtle: fatal turtle file read error: WT_NOTFOUND: item not found"

Еще вопрос. Там по ссылке предлагается такая структура: { _id: ObjectId(...), discussion_id: ObjectId(...), parent_id: ObjectId(...), slug: '34db/8bda' full_slug: '2012.02.08.12.21.08:34db/2012.02.09.22.19.16:8bda', posted: ISODateTime(...), author: { id: ObjectId(...), name: 'Rick' }, text: 'This is so bogus ... ' } Вот объект author содержит id и name. Но то же name можно получить используя populate('User', 'name'). Вопрос: когда стоит и стоит ли вообще использовать populate? Будет ли там такая большая разница в скорости запроса, что лучше хранить вспомогательную информацию типа того же name прямо непосредственно в документе (при этом подписывая себя на то, что придется поддерживать актуальность вспомогательных полей)?

А что за черепашко-файлы?

Нормализация данных оптимизирует их под запись, денормализация оптимизирует под чтение. Если у вас небольшой поток записи или меняются не все поля, но при этом большой объём чтений, то частичная или полная денормализация позволит уменьшить количество чтений необходимых для получения информации. Но вы абсолютно правы — ценой записи. На мой взгляд, денормализация это метод оптимизации — разновидность кеширование. Как следствие этот метод стоит использовать когда есть реальная проблема с объемом чтения, подтверждённая метриками

Afair, это конфигурация wt таблицы хранящейся в WiredTiger.wt, в которой хранится каталог неймспейсов с их настройками

проверил, немного ошибся: WiredTiger.wt это метаданные wt про остальные .wt файлы, по сути точка входа в хранилище. а в виде монговских неймспейсов это уже в таблице _mdb_catalog хранится а turtle файл, да, хранит в себе настойки wt для WiredTiger.wt

Ребят есть кто тут шарит в mongoose? У меня есть поле: items: [{ type: Schema.Types.ObjectId, ref: "Item" }] Но при создании документа, при свойстве setDefaultOnInsert я хочу, чтобы items были по дефолту пустым массивом [] Пробовал сделать так: items: { type: [Schema.Types.ObjectId], ref: "Item", default: [] } Но в этом случае, когда я пытаюсь сделать .populate('items'), у меня ref не цепляется и ссылается сам на себя. А в первом случае при добавлении .populate('items'), ref подцепляется и работает всё ок, но в таком варианте мне не подходит то, что при создании нет пустого массива Кто знает как правильно реализовать defaults?

При добавлении ноды к реплика-сету получаю странную ситуацию - какой-то странный трафик идёт от той и к той ноде, но нет трафика ни с одной другой ноды к этой новой. Сама она находится в состоянии STARTUP, подключиться к ней удалённо получается, но спустя какое-то время она переходит в состояние “(not reachable/healthy)” с ошибкой “connection refused”

ребят, можно оператором как-нибудь юзать $push, чтобы при отсутствии документа в бд, создавался новый? Задал третьим параметром {new: true}, но документ так и не создает

https://docs.mongodb.com/manual/reference/method/db.collection.update/#upsert-option

а, но у вас там upasert

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

привет! А есть ли способ вытащить коллекцию из фс, не поднимая монгу?