Kiến trúc tốt nhất để chuyển đổi JSON sang SQL?

Question

Tôi đã tự hỏi liệu có ai có suy nghĩ về việc chuyển đổi cấu trúc cơ sở dữ liệu tài liệu JSON thành SQL hay không. Nó cần phải được thực hiện để tích hợp/lưu trữ dữ liệu.

Trường JSON tương đối tĩnh, nhưng 'trường' mới có thể xuất hiện sau mỗi 2-4 tuần.

Do tính chất này, và chuyển đổi sang SQL --- tôi đã suy nghĩ ... phân tích tất cả các trường tĩnh vào các trường SQL. Các trường 'động' được cấu trúc trong một phần của tài liệu JSON, thật may mắn.

Ý tưởng của tôi là chỉ cần bỏ 'phần trường động' này có thể chứa 50, 100 trường, những người biết - nó có thể thay đổi chậm --- thành một trường SQL bổ sung.

Bằng cách đó, ít nhất quy trình ETL tương đối tĩnh bất kể các trường JSON thay đổi như thế nào.

Sau đó, một lớp thứ hai hoặc có thể "xem" về cơ bản sẽ phân tích cú pháp cột khổng lồ này thành các trường riêng biệt của nó. IE cột khổng lồ có thể nói "màu sắc: đỏ; trạng thái: mở; thành phố: Rome" ... và một loạt các chức năng chuỗi sẽ phân tích chúng ra để điền vào các màu sắc, trạng thái, và các lĩnh vực thành phố, có thể trong một cái nhìn.

Tôi không chắc liệu đây có phải là suy nghĩ điên rồ hay không. Một lựa chọn khác là thực thi các câu lệnh MySQL một cách nhanh chóng (để thêm các cột) khi chúng gặp phải trong các tài liệu JSON, nhưng đó là tập các vấn đề của riêng nó.

Có ai có suy nghĩ về điều này không?

Và nói rằng cơ sở dữ liệu chỉ được thêm vào, không bao giờ được cập nhật. Trong trường hợp đó, việc 'phân tích' chỉ phải được thực hiện một lần cho mỗi hàng. Liệu một lượt xem vẫn sẽ là lựa chọn tốt nhất? Hoặc chỉ đơn giản là một bảng khác?

Answer 1

Chiến lược đơn giản: Phân tích cú pháp ra khỏi JSON các trường được cố định và bạn biết. Đặt chúng trong các bảng SQL.

Các trường mà bạn không nhận ra, hãy để chúng dưới dạng JSON. Nếu cơ sở dữ liệu hỗ trợ kiểu JSON, hãy đặt nó ở đó. Nếu không, hãy lưu trữ nó trong một trường chuỗi lớn.

Không bắt đầu phân tích cú pháp JSON thành các trường ẩn danh, đặc biệt là khi các trường đang thay đổi trên cơ sở hàng tuần (hoặc lâu hơn). Hầu hết các cơ sở dữ liệu hiện nay hỗ trợ JSON ở một mức độ nào đó, vì vậy bạn có thể sử dụng công cụ cơ sở dữ liệu để phân tích cú pháp khi bạn đang truy vấn dữ liệu.

Answer 2

Có vẻ như bạn có tay cầm trên các trường "tĩnh". Bạn đã cân nhắc sử dụng hệ thống gắn thẻ cho các trường "động" chưa? Có lẽ một bảng lưu trữ một giá trị, một khóa ngoài vào danh sách thẻ chính (danh sách tất cả các trường "tĩnh" sẵn có chứa các định nghĩa kiểu giá trị như chuỗi, int, v.v.) và khóa ngoài cho thực thể mà giá trị trường được liên kết với? Tất nhiên, bạn sẽ phải duy trì một quy trình ETL cho các thẻ chủ đã biết nhưng điều đó dường như đơn giản hóa mọi thứ một chút. Khi các thẻ mới được thêm vào, bạn có thể chỉ cần giới thiệu một số giao dịch SQL được thử nghiệm (hy vọng) có thêm các thẻ mới vào hệ thống của bạn và phiên bản nó cùng với ứng dụng của bạn. Có nói rằng tất cả những gì tôi có thể sẽ tăng thêm một chút và làm một số công việc thiết kế hơn và đưa ra một chiến lược giữ cho mọi thứ nhất quán ở lớp ứng dụng có lợi cho việc cố gắng thực hiện nó ở lớp kiên trì. DDD + Domain Sự kiện, nhà sản xuất/mô hình người tiêu dùng, pub/sub, ngữ nghĩa diễn viên hoặc một số chiến lược khác giải quyết vấn đề thêm lên ngăn xếp của bạn. Có vẻ như hầu hết điều này có thể được gắn vào một số màn hình bảo trì, giữ cho mọi thứ nhất quán ở lớp ứng dụng nếu bạn sẵn sàng thực hiện một số thiết kế lại và xác định lại một số đối tượng/đối tượng kinh doanh của bạn.