Wstawianie dokumentu JSON z kluczem `.` do MongoDB

Po pierwsze, jest to raczej pytanie projektowe niż pytanie programistyczne.

Tworzę aplikację, w której muszę pobrać istniejące dane JSON i wstawić je do MongoDB. Odkryłem, że niektóre dokumenty JSON mają kropkę .w swoim kluczu. Przeczytałem w dokumentacji MongoDB, że kropki .nie są dozwolone jako klucze w MongoDB, ponieważ są używane do tworzenia zapytań.

Nie robię dużo wstawień w aplikacjach internetowych, jest to prawie jednorazowe wstawianie. Ponadto przeważnie pobierałbym cały dokument, zamiast pytać o jego części, ponieważ potrzebuję wszystkich danych.

Biorąc pod uwagę moje wymagania, mam dwie możliwości przechowywania dokumentu JSON:

1. Przeszukaj JSON pod kątem kropki w kluczach i wyjdź z nich, a następnie wstaw je do MongoDB.
2. Konwertuj cały JSON na format BSON i przechowuj je jako takie, unikając w ten sposób potrzeby ucieczki, i ręcznie parsuj JSON, gdy jest to potrzebne poza MongoDB

Czy możesz mi powiedzieć, który projekt byłby lepszy, ponieważ nie jestem w stanie dojść do wniosku.

Istnieje kilka alternatyw:

1. Zastąp kropki kreską.

To byłoby moje ulubione podejście, ponieważ utrzymuje strukturę wystarczająco wyraźną.

Ponieważ według ciebie „jest to prawie jednorazowe wstawienie”, powinno być stosunkowo łatwo sprawdzić, czy niczego nie psuje (tj. Jest już ten sam klawisz z myślnikiem). W innych sytuacjach wykonanie tych kontroli programowo wymaga napisania kodu, ale nadal jest stosunkowo łatwym zadaniem.

2. Zastąp kropki znakiem kropki Unicode, takim jak U + FF0E .

Zdecydowanie odradzałbym to podejście, ponieważ doprowadziłoby to do masowych debugujących bólów głowy na drodze . Pozwalanie komuś, kto używa wynikowego JSON gdzieś w kodzie daleko od MongoDB, odgadnąć, że kropka tak naprawdę nie jest kropką, jest dobrym sposobem na marnowanie dosłownie tygodni czyjegoś czasu. Trzymaj takie sztuczki Unicode dla hakerów, którzy chcą nakłonić kogoś do myślenia, że ​​postać jest inna.

3. Użyj BSON.

Ponieważ twierdzisz, że „przeważnie pobierałbyś cały dokument zamiast pytać o jego części”, takie podejście nie ma poważnych wad w twoim przypadku . Chociaż powiedziałeś „głównie”, co oznacza, że ​​czasami będziesz odzyskiwał tylko części dokumentu.

Ogólnie wadą jest to, że nie można przeszukiwać dokumentu ani ładować tylko jego części.

4. Użyj standardowego kodowania, takiego jak Base64.

Konwersja problematycznych kluczy (lub wszystkich kluczy, w zależności od proporcji między problematycznymi a nieproblemowymi) na Base64 lub heksadecymalną może być realnym rozwiązaniem, z tą korzyścią, że jest dość wyraźna: większość programistów rozpoznaje wartości Base64 lub heksadecymalne na pierwszy rzut oka .

Wadą jest zwiększone zużycie pamięci, a także konieczność kodowania i dekodowania kluczy podczas ich używania.

5. Ustaw check_keysna false.

Zdecydowanie odradzałbym to podejście, ponieważ spowodowałoby to, że zapytanie o dane byłoby niejednoznaczne, i marnowałoby godziny lub dni, próbując dowiedzieć się, dlaczego określone zapytanie nie spełnia oczekiwań. Kropka jest postacią zarezerwowaną, a czek ma na celu ochronę; mówiąc MongoDB, aby pomijał czek, odroczysz tylko moment, w którym będziesz musiał poradzić sobie z konfliktem między składnią MongoDB a zarezerwowanym znakiem używanym w kluczu.

Po prostu użyj BSON. Następnie masz dobrze udokumentowany format z dobrze przetestowaną obsługą bibliotek, a co najważniejsze, możesz go odwrócić (kodować / dekodować) bez strat.