Могу ли я использовать String в качестве типа идентификатора для документа mongodb?

Вы можете использовать любой тип значения для поля _id (кроме массивов). Если вы решите не использовать ObjectId, вам придется как-то гарантировать уникальность значений (подойдет приведение ObjectId к строке). Если вы попытаетесь вставить дубликат ключа, произойдет ошибка, и вам придется с ней бороться.

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

Тем не менее, у вас не должно быть проблем с _id = (new ObjectId).toString().

На самом деле я сделал то же самое, потому что у меня возникла проблема с преобразованием ObjectId в JSON.

Затем я сделал что-то вроде

@Id
private String id;
public String getId() {
    return id();
}
public void setId(String id) {
    this.id = id;
}

И все работало нормально, пока я не решил обновить ранее вставленный документ, когда я получил объект по идентификатору, отправил его на страницу через JSON и получил тот же обновленный объект также по почте JSON, а затем использовал функцию сохранения из хранилища данных вместо обновив предыдущие данные, он вставил новый документ вместо обновления того, который уже был.

Хуже того, у нового документа был тот же идентификатор, что и у ранее вставленного, что я считал невозможным.

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

@Id
private ObjectId id;
public String getId() {
    return id.toString();
}
public void setId(String id) {
    this.id = new ObjectId(id);
}

Да, вы можете использовать строку в качестве _id.

Я бы рекомендовал его, только если у вас есть какое-то значение (в документе), которое, естественно, является хорошим уникальным ключом. Я использовал этот дизайн в одной коллекции, где был строковый геотег вида «xxxxyyyy»; это уникальное для документа поле ДОЛЖНО быть в документе, и мне нужно было создать для него индекс... так почему бы не использовать его в качестве ключа? (Это позволило избежать одной дополнительной пары «ключ-значение» И избежать второго индекса в коллекции, поскольку MondoDB естественным образом строит индекс по «_id». Учитывая размер коллекции, оба из них в сумме дают серьезную экономию места.)

Однако, судя по тону вашего вопроса («Идентификаторы объектов не очень удобны»), если единственная причина, по которой вы хотите использовать строку, заключается в том, что вы не хотите заморачиваться выяснением того, как аккуратно управлять идентификаторами объектов... Я' d предполагают, что стоит потратить время на то, чтобы обдумать их. Я уверен, что они не доставят вам хлопот... как только вы разберетесь с ними.

В противном случае: каковы ваши варианты? Будете ли вы придумывать строковые идентификаторы КАЖДЫЙ РАЗ, когда будете использовать MongoDB в будущем?

Вы также можете использовать строку в качестве идентификатора из Java. Вот пример метода и соответствующий модульный тест, вставляющий один объект со строковым идентификатором в коллекцию MongoDB:

public Document insert(String json, String collectionName) {
    MongoCollection<Document> collection = database.getCollection(collectionName);
    BasicDBObject document = BasicDBObject.parse(json);
    Document doc = new Document(document);
    collection.insertOne(doc);
    return doc;
}

@Test
void whenInsert_ShouldInsertOne() {
    final String uuid = UUID.randomUUID().toString();
    final String collection = "test_collection";
    final Document doc = app.insert(String.format("{\"_id\":\"%s\", \"name\": \"test\"}", 
        uuid), collection);
    assertThat(doc).isNotNull();
    final String json = app.getById(uuid, collection);
    assertThat(json).contains(String.format("\"_id\": \"%s\"", uuid));
}

Я хотел бы добавить, что не всегда хорошая идея использовать автоматически сгенерированный BSON ObjectID в качестве уникального идентификатора, если он передается приложению: пользователь потенциально может манипулировать им.

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

ОБНОВЛЕНИЕ: начиная с версии 3.4+ идентификаторы объектов больше не генерируются постепенно. См. документы 3.2 и последние документы

Таким образом, использование идентификаторов типа UUID обеспечит уровень безопасности через неясность. Конечно, авторизация (разрешен ли этому пользователю доступ к запрашиваемому ресурсу) обязательна, но вы должны знать о вышеупомянутой функции ObjectID.

Чтобы получить лучшее из обоих миров, сгенерируйте UUID, который соответствует длине вашего ObjectID (12 или 24 символа), и используйте его для создания собственного _id типа ObjectID.