Вставлення документа JSON з "." У ключі до MongoDB

По-перше, це більше питання дизайну, ніж питання програмування.

Я створюю додаток, де мені потрібно отримати існуючі дані JSON та вставити їх у MongoDB. Я виявив, що в деяких документах JSON .в їх ключі є період . У документації MongoDB я читав, що періоди .заборонені як ключі в MongoDB, оскільки вони використовуються для запитів.

Я не роблю багато вставок у веб-додатки, це майже одноразова вставка. Крім того, я б здебільшого отримував весь документ, а не запитував його частини, оскільки мені потрібно отримати всі дані.

Отже, враховуючи мої вимоги, у мене є два варіанти, як зберігати документ JSON:

1. Шукайте періодично через JSON у клавішах та уникайте їх, а потім вставляйте їх у MongoDB.
2. Перетворіть весь JSON у формат BSON і зберігайте їх як такі, уникаючи необхідності втечі, і вручну розбирайте JSON, коли це потрібно за межами MongoDB

Не могли б ви сказати мені, що було б кращим дизайном, оскільки я не в змозі прийти до висновку.

Є кілька альтернатив:

1. Замініть крапки на тире.

Це був би мій улюблений підхід, оскільки він зберігає структуру досить чітко.

Оскільки, за вашими словами, "це досить багато часу одноразової вставки", перевірити, чи нічого вона не зламає (тобто вже є однаковий ключ із тире), слід порівняно просто. Для інших ситуацій робити ці перевірки програмно потрібно, щоб написати якийсь код, але це все ще відносно легке завдання.

2. Замініть точки на символ Unicode крапки, наприклад U + FF0E .

Я б настійно не радив такому підходу, оскільки це призведе до масових налагоджуючих головних болів у дорозі . Дозволити тому, хто використовує отриманий JSON десь у коді далеко від MongoDB, здогадатися, що ця точка насправді не є крапкою, це хороший спосіб витрачати буквально тижні чийогось часу. Дотримуйтесь таких хитростей Unicode хакерам, які хочуть обдурити когось, думаючи, що персонаж - це інший.

3. Використовуйте BSON.

Оскільки ви стверджуєте, що "в основному отримаєте весь документ, а не запитуєте його частини", такий підхід у вашому випадку не має великих недоліків . Хоча, ви сказали "в основному", це означає, що іноді ви знайдете лише частини документа.

Загалом недоліком є ​​те, що ви не зможете шукати документ або завантажувати лише його частину.

4. Використовуйте стандартне кодування, наприклад Base64.

Перетворення проблемних ключів (або всіх ключів, залежно від співвідношення між проблемними та непроблемними) в Base64 або шістнадцяткових може бути життєздатним рішенням, з користю бути досить явним: більшість розробників розпізнають Base64 або шістнадцяткові значення з першого погляду .

Недолік - збільшений слід пам'яті, а також необхідність кодування та декодування ключів при їх використанні.

5. Встановити check_keysв false.

Я настійно не рекомендую проти такого підходу, оскільки це зробить запит даних неоднозначним і витрачайте години чи дні, намагаючись з’ясувати, чому конкретний запит не робить те, що ви уявляли, що це має робити. Крапка - це зарезервований символ, і чек знаходиться тут, щоб захистити вас; сказавши MongoDB пропустити чек, ви лише відкладете той момент, коли вам доведеться мати справу з конфліктом між синтаксисом MongoDB та зарезервованим символом, який використовується в ключі.

Просто використовуйте BSON. Тоді у вас є добре задокументований формат, з добре перевіреною підтримкою бібліотеки, і найголовніше, що ви можете його інвертувати (кодувати / декодувати) без втрат.