Cách tốt nhất để lưu trữ dữ liệu người dùng 'bổ sung' trong MySQL?

Question

Tôi đang thêm một tính năng mới vào mô-đun người dùng cho CMS của mình và tôi đã chặn một khối đường ... Hoặc tôi đoán, một ngã ba trên đường và tôi muốn nhận được một số ý kiến ​​từ stackoverflow trước khi tôi cam kết bất cứ điều gì.
Về cơ bản, tôi muốn cho phép quản trị viên thêm các trường người dùng mới 'thêm' mà người dùng có thể điền vào đăng ký, chỉnh sửa trong hồ sơ của họ và/hoặc được kiểm soát bởi các mô-đun khác. Một ví dụ về điều này sẽ là một trường sinh nhật, một mô tả dài của chính họ, hoặc có thể là điểm người dùng đã kiếm được trên trang web. Không cần phải nói, dữ liệu được lưu trữ sẽ khác nhau và có thể dao động từ số lượng lớn văn bản, đến một giá trị số nguyên nhỏ. Để làm cho vấn đề tồi tệ hơn - tôi muốn có tùy chọn để tìm kiếm dữ liệu này.

Bằng cách đó, cách tốt nhất để làm điều này là gì? Ngay bây giờ tôi đang hướng tới việc có một bảng với các cột sau đây.

userid, refFieldID, varchar, tinyint, smallint, int, text, date, datetime, etc. 

Tôi muốn điều này vì nó sẽ giúp tìm kiếm nhanh hơn đáng kể, và các bảng tham chiếu (Mà giữ tất cả dữ liệu của trường, chẳng hạn như tên của lĩnh vực này, cho dù đó là tìm kiếm hay không, vv) có thể tham chiếu cột nào sẽ được sử dụng khi lưu trữ dữ liệu cho trường đó. Một ý tưởng khác, được gợi ý cho tôi và tôi đã nhìn thấy được sử dụng trong các giải pháp khác (vBulletin là một, mặc dù tôi đã thấy những người khác có tên thoát khỏi tôi vào lúc này), nơi bạn chỉ có userid, id tham chiếu và một trường văn bản. Tôi không biết đủ về MySQL để nói điều này với bất kỳ sự chắc chắn nào, nhưng phương pháp này có vẻ như sẽ chậm hơn để tìm kiếm và có thể có chi phí lớn hơn.

Vậy phương pháp nào là 'tốt nhất'? Có phương pháp nào khác mà tôi đang thiếu không? Cho dù phương pháp nào tôi sử dụng, nó cần phải nhanh chóng tìm kiếm, không lớn (Một chút chi phí trên không), và tốt nhất là cho phép các truy vấn phức tạp được sử dụng dựa vào dữ liệu.

Answer 1

Tôi đồng ý rằng bảng khóa-giá trị có lẽ là giải pháp tốt nhất. Độ nghiêng đầu tiên của tôi là chỉ lưu trữ một cột văn bản, như vBulletin đã làm. Tuy nhiên, nếu bạn muốn thêm khả năng lưu trữ dữ liệu mở rộng hơn một chút và có thể tìm kiếm được như bạn đã đặt ra, tôi có thể đề xuất:

• 1 trường trung bình/dài hoặc trung bình/longblob cho văn bản tùy ý/nhị phân lưu trữ (bất cứ điều gì được lưu trữ + trên 3-4 byte cho chuỗi chiều dài). Chỉ có lý do để chọn phương tiện dài hơn là giới hạn những gì có thể được lưu trữ đến 2^24 byte (16,7 MB) so với 2^32 byte (2 GB).
• 1 số nguyên (4 byte) hoặc bigint (8 byte)
• 1 datetime (8 byte)
• Có lẽ 1 float hay double (4-8 bytes) cho nổi lưu trữ điểm

Những lĩnh vực sẽ cho phép bạn lưu trữ gần như bất kỳ loại dữ liệu nào trong bảng nhưng không làm tăng độ rộng của bảng ** (như một varchar) và tránh bất kỳ lưu trữ dư thừa nào (như có tinyint và mediumint, v.v.). Văn bản được lưu trữ trong trường văn bản dài vẫn có thể được tìm kiếm hợp lý bằng cách sử dụng chỉ mục toàn văn hoặc chỉ số độ dài giới hạn thông thường (ví dụ: index longtext_storage(8)).

** tất cả các giá trị blob, chẳng hạn như văn bản dài, được lưu trữ độc lập với bảng chính.

Answer 2

Một kỹ thuật có thể làm việc cho bạn là lưu trữ dữ liệu tùy ý này dưới dạng văn bản, trong một số ký hiệu như JSON, XML hoặc YAML. Quyết định này tùy thuộc vào cách bạn sẽ cần truy cập dữ liệu: nếu bạn chỉ tìm kiếm toàn bộ dữ liệu người dùng của từng người dùng, điều đó có thể lý tưởng. Nếu bạn cần chạy các truy vấn SQL trên các trường cụ thể trong dữ liệu người dùng, bạn sẽ cần phải sử dụng một SQL thuần túy hoặc một phương pháp lai.

Nhiều hệ thống "NoSQL" có khả năng mở rộng cao mới có vẻ ưu tiên dữ liệu JSON (ví dụ: MongoDB, CouchDB và Project Voldemort). Nó đẹp và ngắn gọn, và bạn có thể tạo các cấu trúc phức tạp tùy ý bao gồm các bản đồ (các đối tượng JSON) và các danh sách (các mảng JSON).