JSONB có làm cho mảng PostgreSQL trở nên vô dụng không?

Trong hầu hết các trường hợp, tôi sẽ sử dụng giản đồ chuẩn hóa với một bảng option_tag triển khai mối quan hệ nhiều-nhiều giữa các bảng option và thẻ tag . Tham khảo cách triển khai tại đây:

• Làm thế nào để triển khai mối quan hệ nhiều-nhiều trong PostgreSQL?

Nó có thể không phải là lựa chọn nhanh nhất về mọi mặt, nhưng nó cung cấp đầy đủ các chức năng của DB, bao gồm tính toàn vẹn tham chiếu, các ràng buộc, đầy đủ các loại dữ liệu, tất cả các tùy chọn chỉ mục và các bản cập nhật giá rẻ.

Để hoàn thiện, hãy thêm vào danh sách các tùy chọn của bạn:

• hstore (lựa chọn tốt)
• xml dài dòng hơn và phức tạp hơn hstore hoặc jsonb , vì vậy tôi sẽ chỉ sử dụng nó khi hoạt động với XML.
• "chuỗi các giá trị được phân tách bằng dấu phẩy" (rất đơn giản, hầu hết là tùy chọn không hợp lệ)
• EAV (Thực thể-Thuộc tính-Giá trị) hoặc "cặp tên-giá trị" (hầu hết là tùy chọn không hợp lệ)
  Chi tiết về câu hỏi liên quan này trên dba.SE:
  • Có tên cho cấu trúc cơ sở dữ liệu này không?

Nếu danh sách chỉ để hiển thị và hiếm khi được cập nhật, tôi sẽ xem xét một mảng thuần túy, thường nhỏ hơn và hoạt động tốt hơn cho phần còn lại.

Đọc mục blog của Josh Berkus @a_horse được liên kết đến trong nhận xét của anh ấy. Nhưng hãy lưu ý rằng nó tập trung vào các trường hợp đã đọc được chọn. Josh thừa nhận:

Và đó là nơi mà phương pháp chuẩn hóa sẽ thắng lợi, đặc biệt là khi bạn thay đổi nhiều thẻ đơn khi tải đồng thời.

jsonb chỉ là một lựa chọn tốt nếu bạn vẫn sử dụng JSON và có thể lưu trữ và truy xuất JSON "nguyên trạng".