Cập nhật ngày 4 tháng 6 năm 2017
Cho rằng câu hỏi / câu trả lời này đã trở nên phổ biến, tôi nghĩ rằng nó đáng để cập nhật.
Khi câu hỏi này ban đầu được đăng, MySQL không có hỗ trợ cho các kiểu dữ liệu JSON và hỗ trợ trong PostgreSQL đang ở giai đoạn sơ khai. Kể từ 5.7, MySQL hiện hỗ trợ kiểu dữ liệu JSON (ở định dạng lưu trữ nhị phân) và PostgreSQL JSONB đã trưởng thành đáng kể. Cả hai sản phẩm đều cung cấp các loại JSON hiệu quả có thể lưu trữ các tài liệu tùy ý, bao gồm hỗ trợ lập chỉ mục các khóa cụ thể của đối tượng JSON.
Tuy nhiên, tôi vẫn giữ nguyên tuyên bố ban đầu của mình rằng tùy chọn mặc định của bạn, khi sử dụng cơ sở dữ liệu quan hệ, vẫn phải là cột mỗi giá trị. Cơ sở dữ liệu quan hệ vẫn được xây dựng dựa trên giả định rằng dữ liệu bên trong chúng sẽ được chuẩn hóa khá tốt. Công cụ lập kế hoạch truy vấn có thông tin tối ưu hóa tốt hơn khi xem các cột so với khi xem các khóa trong tài liệu JSON. Khóa ngoại có thể được tạo giữa các cột (nhưng không phải giữa các khóa trong tài liệu JSON). Quan trọng:nếu phần lớn lược đồ của bạn đủ biến động để sử dụng JSON, thì ít nhất bạn có thể muốn xem xét xem cơ sở dữ liệu quan hệ có phải là lựa chọn phù hợp hay không.
Điều đó nói rằng, rất ít ứng dụng hoàn toàn mang tính quan hệ hoặc hướng tài liệu. Hầu hết các ứng dụng có một số kết hợp của cả hai. Dưới đây là một số ví dụ mà cá nhân tôi thấy JSON hữu ích trong cơ sở dữ liệu quan hệ:
-
Khi lưu trữ địa chỉ email và số điện thoại cho một liên hệ, nơi lưu trữ chúng dưới dạng giá trị trong một mảng JSON sẽ dễ quản lý hơn nhiều so với nhiều bảng riêng biệt
-
Lưu tùy chọn khóa / giá trị tùy ý của người dùng (trong đó giá trị có thể là boolean, văn bản hoặc số và bạn không muốn có các cột riêng biệt cho các kiểu dữ liệu khác nhau)
-
Lưu trữ dữ liệu cấu hình không có lược đồ xác định (nếu bạn đang xây dựng Zapier hoặc IFTTT và cần lưu trữ dữ liệu cấu hình cho mỗi lần tích hợp)
Tôi chắc rằng cũng có những người khác, nhưng đây chỉ là một vài ví dụ nhanh.
Câu trả lời ban đầu
Nếu bạn thực sự muốn có thể thêm bao nhiêu trường tùy thích mà không bị giới hạn (ngoài giới hạn kích thước tài liệu tùy ý), hãy xem xét giải pháp NoSQL chẳng hạn như MongoDB.
Đối với cơ sở dữ liệu quan hệ:sử dụng một cột cho mỗi giá trị. Đặt một blob JSON trong một cột khiến nó hầu như không thể truy vấn (và rất chậm khi bạn thực sự tìm thấy một truy vấn hoạt động).
Cơ sở dữ liệu quan hệ tận dụng lợi thế của các loại dữ liệu khi lập chỉ mục và được thiết kế để thực hiện với một chuẩn hóa cấu trúc.
Một lưu ý phụ:điều này không có nghĩa là bạn không bao giờ nên lưu trữ JSON trong cơ sở dữ liệu quan hệ. Nếu bạn đang thêm siêu dữ liệu thực hoặc nếu JSON của bạn đang mô tả thông tin mà không cần phải truy vấn và chỉ được sử dụng để hiển thị, có thể quá mức cần thiết để tạo một cột riêng cho tất cả các điểm dữ liệu.
