Insertion d'un document JSON avec `.` dans la clé de MongoDB

Tout d'abord, il s'agit plus d'une question de conception que d'une question de programmation.

Je crée une application où je dois récupérer les données JSON existantes et les insérer dans MongoDB. J'ai trouvé que certains des documents JSON ont une période .dans leur clé. J'ai lu dans la documentation MongoDB que les périodes .ne sont pas autorisées comme clés dans MongoDB car elles sont utilisées pour les requêtes.

Je ne fais pas beaucoup d'insertions dans les applications Web, c'est à peu près une insertion unique. De plus, je récupérerais la plupart du temps le document plutôt que d'en demander des parties car j'ai besoin d'obtenir toutes les données.

Donc, compte tenu de mes besoins, j'ai deux choix sur la façon de stocker le document JSON:

1. Recherchez dans le JSON la période dans les clés et échappez-les, puis insérez-les dans MongoDB.
2. Convertissez l'intégralité du JSON au format BSON et stockez-les en tant que tels, évitant ainsi la nécessité de s'échapper, et analysez manuellement le JSON en cas de besoin en dehors de MongoDB

Pourriez-vous me dire quel serait un meilleur design, car je ne suis pas en mesure de conclure.

Il existe quelques alternatives:

1. Remplacez les points par un tiret.

Ce serait mon approche préférée, car elle maintient la structure suffisamment explicite.

Puisque selon vous, «c'est à peu près une insertion unique», il devrait être relativement simple de vérifier s'il ne casse rien (c'est-à-dire qu'il y a déjà une même clé avec un tiret). Pour d'autres situations, effectuer ces vérifications par programme nécessite d'écrire du code, mais reste une tâche relativement facile.

2. Remplacez les points par un caractère de point Unicode tel que U + FF0E .

Je déconseille fortement cette approche, car elle entraînerait des maux de tête de débogage massifs sur la route . Laisser quelqu'un qui utilise le JSON résultant quelque part dans le code loin de MongoDB deviner qu'un point n'est pas vraiment un point est un bon moyen de perdre littéralement des semaines de temps. Gardez ces astuces Unicode pour les pirates qui veulent inciter quelqu'un à penser qu'un personnage est différent.

3. Utilisez BSON.

Dans la mesure où vous prétendez que vous "récupéreriez principalement le document entier plutôt que d'en interroger des parties", cette approche n'a pas d'inconvénients majeurs dans votre cas . Bien que vous ayez dit «principalement», ce qui signifie que parfois, vous ne récupérerez que des parties du document.

En général, l'inconvénient est que vous ne pourrez pas rechercher dans le document ou en charger seulement une partie.

4. Utilisez un encodage standard, tel que Base64.

La conversion des clés problématiques (ou de toutes les clés, selon le rapport entre celles problématiques et non problématiques) en Base64 ou hexadécimal pourrait être une solution viable, avec l'avantage d'être plutôt explicite: la plupart des développeurs reconnaîtraient les valeurs Base64 ou hexadécimales en un coup d'œil .

L'inconvénient est l'empreinte mémoire accrue, ainsi que la nécessité d'encoder et de décoder les clés lors de leur utilisation.

5. Réglez check_keyssur false.

Je déconseille fortement cette approche, car cela rendrait la requête de données ambiguë et gaspillerait des heures ou des jours à essayer de comprendre pourquoi une requête spécifique ne fait pas ce que vous imaginiez qu'elle devrait faire. Le point est un caractère réservé et le chèque est là pour vous protéger; en disant à MongoDB de sauter la vérification, vous ne reporterez que le moment où vous devrez faire face à un conflit entre la syntaxe de MongoDB et le caractère réservé utilisé dans une clé.

Utilisez simplement BSON. Ensuite, vous avez un format bien documenté, avec un support de bibliothèque bien testé, et surtout vous pouvez l'inverser (encoder / décoder) sans perte.