Kann ich String als ID-Typ für das mongodb-Dokument verwenden?

Sie können einen beliebigen Werttyp für ein _id -Feld verwenden (außer für Arrays). Wenn Sie ObjectId nicht verwenden möchten, müssen Sie irgendwie die Eindeutigkeit der Werte garantieren (Casting ObjectId to string macht das). Wenn Sie versuchen, einen doppelten Schlüssel einzufügen, tritt ein Fehler auf und Sie müssen sich damit befassen.

Ich bin mir nicht sicher, welchen Effekt es auf sharded Cluster haben wird, wenn Sie versuchen, zwei Dokumente mit derselben _id zu verschiedenen Shards einzufügen. Ich vermute, dass es dich einfügen lässt, aber das wird dich später beißen. (Ich muss das testen).

Das heißt, Sie sollten keine Probleme mit _id = (new ObjectId).toString() haben.

Ich habe das gleiche gemacht, weil ich Probleme hatte, die ObjectId in JSON zu konvertieren.

Ich habe dann etwas wie

Und alles funktionierte gut, bis ich beschloss, ein zuvor eingefügtes Dokument zu aktualisieren, als ich das Objekt per ID über JSON an die Seite schickte und das gleiche aktualisierte Objekt auch per JSON-Post erhielt und dann die Speicherfunktion aus dem Datenspeicher verwendete Anstatt die vorherigen Daten zu aktualisieren, wurde ein neues Dokument eingefügt, anstatt das bereits vorhandene zu aktualisieren.

Am schlimmsten war, dass das neue Dokument dieselbe ID hatte wie die zuvor eingefügte, was ich für unmöglich hielt.

Wie auch immer, ich habe das private Objekt als ObjectID gesetzt und das get einfach als String gesetzt und dann hat es wie erwartet funktioniert, nicht sicher, ob das in Ihrem Fall hilft.

Ja, Sie können eine Zeichenfolge als _id verwenden.

Ich würde es nur empfehlen, wenn Sie einen Wert (im Dokument) haben, der natürlich ein guter eindeutiger Schlüssel ist. Ich habe dieses Design in einer Sammlung verwendet, wo es ein String-Geo-Tag gab, in der Form "xxxxyyyy"; Dieses Dokument für jedes Dokument musste sich im Dokument befinden und Ich musste einen Index dafür erstellen ... also warum nicht als Schlüssel verwenden? (Dies vermied ein zusätzliches Schlüssel / Wert-Paar UND vermied einen zweiten Index für die Sammlung, da MondoDB natürlich einen Index für "_id" erstellt. Angesichts der Größe der Sammlung summierten sich beide zu beträchtlichen Platzeinsparungen.)

Aus dem Tonfall Ihrer Frage ("Objekt-IDs sind nicht sehr praktisch") möchten Sie jedoch nicht nur herausfinden, wie Sie Objekt-IDs sauber verwalten können. Ich schlage vor, es ist Ihre Zeit wert, sich um sie zu kümmern. Ich bin mir sicher, dass sie keine Probleme haben ... sobald du deine Probleme mit ihnen herausgefunden hast.

Ansonsten: Was sind Ihre Möglichkeiten? Werden Sie jedes Mal, wenn Sie in Zukunft MongoDB verwenden, String-IDs erstellen?

Ich möchte hinzufügen, dass es nicht immer eine gute Idee ist, die automatisch generierte BSON ObjectID als eindeutigen Bezeichner zu verwenden, wenn sie an die Anwendung übergeben wird: Sie kann möglicherweise vom Benutzer manipuliert werden. ObjectIDs werden scheinbar sequenziell generiert. Wenn Sie die erforderlichen Autorisierungsmechanismen nicht implementieren, kann der böswillige Benutzer einfach den Wert erhöhen, den er hat, um auf Ressourcen zuzugreifen, auf die er keinen Zugriff haben sollte.

Daher wird die Verwendung von UUID-Typ-IDs eine Sicherheitsebene für die Sicherheit bieten. Natürlich ist die Autorisierung (ist dieser Benutzer erlaubt, auf die angeforderte Ressource zuzugreifen) ein Muss, aber Sie sollten sich der oben erwähnten ObjectID-Funktion bewusst sein.

Um das Beste aus beiden Welten zu erhalten, generieren Sie eine UUID, die Ihrer ObjectID-Länge entspricht (12 oder 24 Zeichen) und verwenden Sie diese, um Ihre eigene _id des ObjectID-Typs zu erstellen.