Chèn tài liệu JSON có khóa `.` vào MongoDB

Thứ nhất, đây là một câu hỏi thiết kế nhiều hơn là một câu hỏi lập trình.

Tôi đang tạo một ứng dụng mà tôi phải tìm nạp dữ liệu JSON hiện có và chèn nó vào MongoDB. Tôi thấy rằng một số tài liệu JSON có một khoảng thời gian .trong khóa của chúng. Tôi đã đọc trong tài liệu MongoDB rằng các dấu chấm .không được phép làm khóa trong MongoDB vì chúng được sử dụng để truy vấn.

Tôi không thực hiện nhiều thao tác chèn trong các ứng dụng web, nó chỉ là một lần chèn. Ngoài ra, tôi chủ yếu sẽ lấy toàn bộ tài liệu thay vì truy vấn các phần của nó vì tôi cần lấy tất cả dữ liệu.

Vì vậy, xem xét các yêu cầu của tôi, tôi có hai lựa chọn về cách lưu trữ tài liệu JSON:

1. Tìm kiếm thông qua JSON trong khoảng thời gian trong các khóa và thoát chúng và sau đó chèn chúng vào MongoDB.
2. Chuyển đổi toàn bộ JSON thành định dạng BSON và lưu trữ chúng như vậy, do đó tránh được yêu cầu thoát và phân tích thủ công JSON khi cần bên ngoài MongoDB

Bạn có thể cho tôi biết đó sẽ là một thiết kế tốt hơn, vì tôi không thể đưa ra kết luận.

Có một vài lựa chọn thay thế:

1. Thay thế dấu chấm bằng dấu gạch ngang.

Đây sẽ là cách tiếp cận yêu thích của tôi, vì nó giữ cho cấu trúc đủ rõ ràng.

Vì theo bạn, thì nó khá giống với việc chèn một lần, nên nó khá đơn giản để kiểm tra xem nó có phá vỡ gì không (tức là đã có cùng một khóa với dấu gạch ngang). Đối với các tình huống khác, thực hiện các kiểm tra đó theo chương trình yêu cầu viết một số mã, nhưng vẫn là một nhiệm vụ tương đối dễ dàng.

2. Thay thế các dấu chấm bằng một ký tự chấm Unicode, chẳng hạn như U + FF0E .

Tôi sẽ khuyên bạn nên chống lại cách tiếp cận này, vì nó sẽ dẫn đến những cơn đau đầu lớn . Để ai đó sử dụng JSON kết quả ở đâu đó trong mã cách xa MongoDB để đoán rằng một dấu chấm không thực sự là một dấu chấm là một cách tốt để lãng phí hàng tuần thời gian của một ai đó. Giữ các thủ thuật Unicode như vậy cho các tin tặc muốn lừa ai đó nghĩ rằng một nhân vật là một nhân vật khác.

3. Sử dụng BSON.

Vì bạn cho rằng bạn hầu như sẽ truy xuất toàn bộ tài liệu thay vì truy vấn các phần của nó, nên cách tiếp cận này không có nhược điểm lớn trong trường hợp của bạn . Mặc dù, bạn đã nói rằng, chủ yếu là, có nghĩa là đôi khi, bạn sẽ chỉ truy xuất các phần của tài liệu.

Nói chung, nhược điểm là bạn sẽ không thể tìm kiếm thông qua tài liệu hoặc chỉ tải một phần của tài liệu đó.

4. Sử dụng mã hóa tiêu chuẩn, chẳng hạn như Base64.

Chuyển đổi các khóa có vấn đề (hoặc tất cả các khóa, tùy thuộc vào tỷ lệ giữa các khóa có vấn đề và không có vấn đề) thành Base64 hoặc hexadecimal có thể là một giải pháp khả thi, với lợi ích là khá rõ ràng: hầu hết các nhà phát triển sẽ nhận ra các giá trị Base64 hoặc hexadecimal trong nháy mắt .

Hạn chế là dấu chân bộ nhớ tăng lên, cũng như sự cần thiết phải mã hóa và giải mã các phím khi sử dụng chúng.

5. Đặt check_keysthành false.

Tôi đặc biệt khuyên bạn nên chống lại cách tiếp cận này, vì nó sẽ làm cho truy vấn dữ liệu trở nên mơ hồ và lãng phí hàng giờ hoặc hàng ngày để tìm hiểu tại sao một truy vấn cụ thể không làm những gì bạn tưởng tượng nên làm. Dot là một nhân vật dành riêng và kiểm tra ở đây để bảo vệ bạn; bằng cách yêu cầu MongoDB bỏ qua kiểm tra, bạn sẽ chỉ hoãn lại khoảnh khắc mà bạn sẽ phải giải quyết mâu thuẫn giữa cú pháp của MongoDB và ký tự dành riêng được sử dụng trong một khóa.

Chỉ cần sử dụng BSON. Sau đó, bạn có một định dạng tài liệu tốt, với sự hỗ trợ thư viện được kiểm tra tốt, và quan trọng nhất là bạn có thể đảo ngược nó (mã hóa / giải mã) mà không mất.