Để trả lời:có vẻ như text không được dùng trong nhiều DBMS, vì vậy tốt hơn nên sử dụng blob hoặc varchar với giới hạn cao (và với blob, bạn sẽ không gặp bất kỳ vấn đề mã hóa nào, đây là một rắc rối lớn với varchar và text) .
Cũng như đã chỉ ra trong chuỗi này tại diễn đàn MySQL , ổ cứng rẻ hơn phần mềm, vì vậy trước tiên bạn nên thiết kế phần mềm của mình và làm cho nó hoạt động, và chỉ sau đó nếu dung lượng trở thành vấn đề, bạn có thể muốn tối ưu hóa khía cạnh đó. Vì vậy, đừng cố gắng tối ưu hóa quá sớm kích thước cột của bạn, tốt hơn nên đặt kích thước lớn hơn lúc đầu (cộng với điều này sẽ tránh được các vấn đề về bảo mật).
Về các nhận xét khác nhau:Quá cuồng tín SQL ở đây. Mặc dù thực tế là tôi rất thích SQL và các mô hình quan hệ, chúng cũng có những cạm bẫy.
Lưu trữ dữ liệu được tuần tự hóa vào cơ sở dữ liệu nguyên trạng (chẳng hạn như lưu trữ dữ liệu có định dạng JSON hoặc XML) có một số ưu điểm:
- Bạn có thể có một định dạng linh hoạt hơn cho dữ liệu của mình:thêm và xóa các trường một cách nhanh chóng, thay đổi đặc điểm của các trường một cách nhanh chóng, v.v. ...
- Ít trở kháng không phù hợp với mô hình đối tượng:bạn lưu trữ và bạn tìm nạp dữ liệu giống như trong chương trình của mình, so với việc tìm nạp dữ liệu và sau đó phải xử lý và chuyển đổi nó giữa các cấu trúc của đối tượng chương trình và cấu trúc của cơ sở dữ liệu quan hệ của bạn .
Và còn rất nhiều ưu điểm khác nữa, vì vậy xin đừng có chủ nghĩa cuồng tín:cơ sở dữ liệu quan hệ là một công cụ tuyệt vời, nhưng đừng bỏ qua những công cụ khác mà chúng ta có thể có được. Nhiều công cụ hơn, càng tốt.
Đối với một ví dụ cụ thể về việc sử dụng, tôi có xu hướng thêm trường JSON vào cơ sở dữ liệu của mình để lưu trữ các tham số bổ sung của bản ghi trong đó các cột (thuộc tính) của dữ liệu JSON sẽ không bao giờ được CHỌN riêng lẻ, mà chỉ được sử dụng khi bản ghi phù hợp đã được chọn. Trong trường hợp này, tôi vẫn có thể phân biệt các bản ghi của mình với các cột quan hệ và khi bản ghi phù hợp được chọn, tôi chỉ có thể sử dụng các tham số bổ sung cho bất kỳ mục đích nào mình muốn.
Vì vậy, lời khuyên của tôi để giữ lại những gì tốt nhất của cả thế giới (tốc độ, khả năng tuần tự hóa và tính linh hoạt của cấu trúc), chỉ cần sử dụng một vài cột quan hệ tiêu chuẩn để làm khóa duy nhất để phân biệt giữa các hàng của bạn và sau đó sử dụng cột blob / varchar nơi dữ liệu được tuần tự hóa của bạn sẽ được chèn vào. Thông thường, chỉ cần hai / ba cột cho một khóa duy nhất, do đó, đây sẽ không phải là một chi phí lớn.
Ngoài ra, bạn có thể quan tâm đến PostgreSQL hiện có kiểu dữ liệu JSON và dự án PostSQL để xử lý trực tiếp các trường JSON giống như các cột quan hệ.
