Có vẻ như bạn chủ yếu quan tâm đến hiệu suất.
Một vài người đã đề xuất tách thành 3 bảng (bảng danh mục cộng với bảng tham chiếu chéo đơn giản hoặc một cách phức tạp hơn để lập mô hình phân cấp cây, như tập hợp lồng nhau hoặc đường dẫn cụ thể hóa), đó là điều đầu tiên tôi nghĩ khi đọc câu hỏi của bạn .
Với các chỉ mục, một cách tiếp cận hoàn toàn chuẩn hóa như vậy (thêm hai THAM GIA) sẽ vẫn có hiệu suất đọc "khá tốt". Một vấn đề là INSERT hoặc UPDATE cho một sự kiện bây giờ cũng có thể bao gồm một hoặc nhiều INSERT / UPDATE / DELETE vào bảng tham chiếu chéo, điều này trên MyISAM có nghĩa là bảng tham chiếu chéo bị khóa và trên InnoDB có nghĩa là các hàng bị khóa, vì vậy nếu cơ sở dữ liệu của bạn đang bận với một số lượng lớn các lần ghi, bạn sẽ gặp phải vấn đề tranh chấp lớn hơn nếu chỉ các hàng sự kiện bị khóa.
Cá nhân tôi sẽ thử cách tiếp cận hoàn toàn bình thường hóa này trước khi tối ưu hóa. Nhưng, tôi sẽ cho rằng bạn biết mình đang làm gì, rằng giả định của bạn là đúng (các danh mục không bao giờ thay đổi) và bạn có một kiểu sử dụng (nhiều lần viết) yêu cầu cấu trúc phẳng, ít chuẩn hóa hơn. Điều đó hoàn toàn ổn và là một phần của NoSQL.
SET so với "nhiều cột"
Vì vậy, đối với câu hỏi thực tế của bạn "SET so với rất nhiều cột", tôi có thể nói rằng tôi đã làm việc với hai công ty với các kỹ sư thông minh (có sản phẩm là ứng dụng web CRM ... một thực sự là quản lý sự kiện) và cả hai đều đã sử dụng phương pháp tiếp cận "nhiều cột" cho loại dữ liệu tập hợp tĩnh này.
Lời khuyên của tôi là hãy suy nghĩ về tất cả các truy vấn bạn sẽ thực hiện trên bảng này (được tính theo tần suất của chúng) và cách các chỉ mục sẽ hoạt động.
Trước tiên, với phương pháp tiếp cận "nhiều cột", bạn sẽ cần chỉ mục trên mỗi cột này để bạn có thể thực hiện SELECT FROM events WHERE CategoryX = TRUE . Với các chỉ mục, đó là một truy vấn siêu nhanh.
So với SET, bạn phải sử dụng bitwise AND (&), LIKE hoặc FIND_IN_SET () để thực hiện truy vấn này. Điều đó có nghĩa là truy vấn không thể sử dụng chỉ mục và phải thực hiện tìm kiếm tuyến tính đối với tất cả các hàng (bạn có thể sử dụng GIẢI THÍCH để xác minh điều này). Truy vấn chậm!
Đó là lý do chính khiến SET là một ý tưởng tồi - chỉ mục của nó chỉ hữu ích nếu bạn đang chọn theo các nhóm danh mục chính xác. SET hoạt động tốt nếu bạn đang chọn danh mục theo sự kiện, nhưng không phải ngược lại.
Vấn đề chính của phương pháp tiếp cận "nhiều cột" ít được chuẩn hóa (so với chuẩn hóa hoàn toàn) là nó không mở rộng quy mô. Nếu bạn có 5 danh mục và chúng không bao giờ thay đổi, tốt thôi, nhưng nếu bạn có 500 và đang thay đổi chúng, đó là một vấn đề lớn. Trong kịch bản của bạn, với khoảng 30 mà không bao giờ thay đổi, vấn đề chính là có một chỉ mục trên mỗi cột, vì vậy nếu bạn đang ghi thường xuyên, những truy vấn đó sẽ trở nên chậm hơn do số lượng chỉ mục phải cập nhật. Nếu bạn chọn cách tiếp cận này, bạn có thể muốn kiểm tra nhật ký truy vấn chậm của MySQL để đảm bảo không có truy vấn chậm hơn do tranh cãi vào những thời điểm bận rộn trong ngày.
Trong trường hợp của bạn, nếu ứng dụng web của bạn là một ứng dụng web đọc nhiều điển hình, tôi nghĩ rằng việc sử dụng phương pháp tiếp cận "nhiều cột" (như hai sản phẩm CRM đã làm, vì lý do tương tự) có lẽ là điều hợp lý. Nó chắc chắn là nhanh hơn SET cho truy vấn SELECT đó.
TL; DR Không sử dụng SET vì truy vấn "chọn sự kiện theo danh mục" sẽ chậm.
