Như thường lệ - nó phụ thuộc.
Thứ nhất, có số cột tối đa mà MySQL có thể hỗ trợ và bạn không thực sự muốn đến đó.
Thứ hai, có tác động đến hiệu suất khi chèn hoặc cập nhật nếu bạn có nhiều cột có chỉ mục (mặc dù tôi không chắc liệu điều này có quan trọng trên phần cứng hiện đại hay không).
Thứ ba, các bảng lớn thường là bãi chứa cho tất cả dữ liệu có vẻ liên quan đến thực thể cốt lõi; điều này nhanh chóng làm cho thiết kế không rõ ràng. Ví dụ:thiết kế bạn trình bày hiển thị 3 trường loại "trạng thái" khác nhau (trạng thái, is_admin và fb_account_verified) - Tôi nghi ngờ rằng có một số logic nghiệp vụ sẽ liên kết các trường đó với nhau (ví dụ:quản trị viên phải là người dùng đã xác minh), nhưng thiết kế không hỗ trợ điều đó.
Đây có thể là một vấn đề - đó là một câu hỏi về khái niệm, kiến trúc / thiết kế hơn là một hiệu suất / nó sẽ hoạt động. Tuy nhiên, trong những trường hợp như vậy, bạn có thể cân nhắc việc tạo các bảng để phản ánh thông tin liên quan về tài khoản, ngay cả khi nó không có mối quan hệ x-nhiều. Vì vậy, bạn có thể tạo "user_profile", "user_credentials", "user_fb", "user_activity", tất cả được liên kết bởi user_id. Điều này làm cho nó gọn gàng hơn và nếu bạn phải thêm nhiều trường liên quan đến facebook, chúng sẽ không bị treo ở cuối bảng. Tuy nhiên, nó sẽ không làm cho cơ sở dữ liệu của bạn nhanh hơn hoặc có thể mở rộng hơn. Chi phí tham gia có thể không đáng kể.
Bất kể bạn làm gì, tùy chọn 2 - tuần tự hóa "các trường hiếm khi được sử dụng" thành một trường văn bản duy nhất - là một ý tưởng tồi. Bạn không thể xác thực dữ liệu (vì vậy ngày tháng có thể không hợp lệ, số có thể là văn bản, có thể thiếu giá trị không) và bất kỳ việc sử dụng nào trong mệnh đề "where" trở nên rất chậm.
Một giải pháp thay thế phổ biến là các cửa hàng "Thực thể / Thuộc tính / Giá trị" hoặc "Khóa / Giá trị". Giải pháp này có một số lợi ích - bạn có thể lưu trữ dữ liệu của mình trong cơ sở dữ liệu quan hệ ngay cả khi lược đồ của bạn thay đổi hoặc không xác định tại thời điểm thiết kế. Tuy nhiên, chúng cũng có nhược điểm:khó xác thực dữ liệu ở cấp cơ sở dữ liệu (kiểu dữ liệu và khả năng vô hiệu), khó tạo liên kết có ý nghĩa đến các bảng khác bằng cách sử dụng các mối quan hệ khóa ngoại và việc truy vấn dữ liệu có thể trở nên rất phức tạp - hãy tưởng tượng việc tìm kiếm tất cả ghi lại trạng thái là 1 và facebook_id là không và ngày đăng ký lớn hơn ngày hôm qua.
Cho rằng bạn dường như biết lược đồ dữ liệu của mình, tôi muốn nói rằng "khóa / giá trị" không phải là một lựa chọn tốt.
