Đầu tiên là bình thường hóa hơn, nếu hơi không đầy đủ. Có một số cách tiếp cận mà bạn có thể thực hiện, cách đơn giản nhất (và nói đúng ra là 'đúng' nhất) sẽ cần hai bảng, với ràng buộc FK rõ ràng.
commentid ---- subjectid ----- idType
--------------------------------------
1 22 post
2 26 photo
3 84 reply
4 36 post
5 22 status
idType
------
post
photo
reply
status
Nếu muốn, bạn có thể sử dụng ký tự (1) hoặc ký tự tương tự để giảm tác động của varchar lên độ dài khóa / chỉ mục hoặc để tạo điều kiện sử dụng với ORM nếu bạn định sử dụng. NULL luôn là một vấn đề đáng lo ngại và nếu bạn bắt đầu thấy chúng xuất hiện trong thiết kế của mình, bạn sẽ tốt hơn nếu bạn có thể tìm ra một cách thuận tiện để loại bỏ chúng.
Cách tiếp cận thứ hai là cách tôi thích hơn khi xử lý hơn 100 triệu hàng:
commentid ---- subjectid
------------------------
1 22
2 26
3 84
4 36
5 22
postIds ---- subjectid
----------------------
1 22
4 36
photoIds ---- subjectid
-----------------------
2 26
replyIds ---- subjectid
-----------------------
3 84
statusIds ---- subjectid
------------------------
5 22
Tất nhiên cũng có phương pháp kết hợp (hơi không chuẩn hóa), mà tôi sử dụng rộng rãi với các bộ dữ liệu lớn, vì chúng có xu hướng bẩn. Chỉ cần cung cấp các bảng chuyên môn cho idTypes được xác định trước, nhưng giữ một cột idType adhoc trên bảng commentId.
Lưu ý rằng ngay cả phương pháp kết hợp cũng chỉ yêu cầu 2x không gian của bảng không chuẩn hóa; và cung cấp hạn chế truy vấn tầm thường bởi idType. Tuy nhiên, ràng buộc toàn vẹn không thẳng tiến, là một ràng buộc FK trên một UNION dẫn xuất của bảng kiểu. Phương pháp chung của tôi là sử dụng trình kích hoạt trên bảng kết hợp hoặc chế độ xem có thể cập nhật tương đương để đưa ra các bản cập nhật cho bảng loại phụ chính xác.
Cả cách tiếp cận đơn giản và cách tiếp cận bảng kiểu phụ phức tạp hơn đều hoạt động; Tuy nhiên, đối với hầu hết các mục đích, KISS được áp dụng, vì vậy tôi nghi ngờ rằng bạn có thể chỉ nên giới thiệu một bảng ID_TYPES, FK có liên quan và được thực hiện với nó.
