Khi hai bảng rất giống nhau, khi nào chúng nên được kết hợp?

Question

Tôi có các sự kiện và ảnh và sau đó là nhận xét cho cả hai. Ngay bây giờ, tôi có hai bình luận bảng, một cho ý kiến ​​liên quan đến các sự kiện, và một cho ý kiến ​​hình ảnh. Schema là tương tự như sau:

CREATE TABLE EventComments 
(
    CommentId int, 
    EventId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
) 

CREATE TABLE PhotoComments 
(
    CommentId int, 
    PhotoId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
) 

Câu hỏi của tôi là có hay không tôi nên kết hợp chúng, và thêm một bảng tham chiếu chéo riêng biệt, nhưng tôi không thể nghĩ ra một cách để làm điều đó đúng. Tôi nghĩ điều này sẽ ổn thôi, suy nghĩ của bạn là gì?

Sửa

Dựa trên câu trả lời của Walter (và một số ánh sáng đọc), tôi đã đi lên với điều này:

CREATE TABLE Comments 
(
    CommentId int, 
    Comment NVarChar(250), 
    DateSubmitted datetime 
    CONTRAINT [PK_Comments] PRIMARY KEY 
    (
    CommentId 
) 
) 

CREATE TABLE EventComments 
(
    CommentId int, 
    EventId int 
) 

CREAT TABLE PhotoComments 
(
    CommentId int, 
    PhotoId int 
) 

ALTER TABLE EventComments ADD CONSTRAINT FK_EventComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId) 

ALTER TABLE PhotoComments ADD CONSTRAINT FK_PhotoComments FOREIGN KEY (CommentId) REFERENCES Comments(CommentId) 

Có thực sự bất kỳ sự khác biệt về hiệu năng giữa các cấu trúc? Đối với tôi, nó có vẻ như một chút ưu tiên. Tôi thấy lợi ích trong lược đồ thứ hai, nếu tôi muốn thêm một số tính năng vào nhận xét sự kiện hoặc nhận xét ảnh, tôi có một bảng riêng để làm như vậy và nếu tôi muốn cả hai chia sẻ một thuộc tính mới, có một bảng thêm thuộc tính mới.

Answer 1

Nhận xét, PhotoComments và EventComments có liên quan trong một mẫu gọi là "chuyên môn hóa tổng quát". Mẫu này được xử lý bởi sự kế thừa đơn giản trong các ngôn ngữ hướng đối tượng. Đó là một chút phức tạp hơn để thiết lập một lược đồ của các bảng sẽ chụp cùng một mẫu.

Nhưng nó được hiểu rõ. Tìm kiếm nhanh trên google về "mô hình hóa quan hệ hóa chuyên môn hóa tổng quát" sẽ cung cấp cho bạn một số bài viết hay về chủ đề này.

Answer 2

Bạn có thể kết hợp chúng và thêm trường cho biết đó là trường cho ảnh hoặc sự kiện.

Bạn sẽ cần hai khóa ngoại; một cho hình ảnh và một cho các sự kiện, nhưng có chúng trong một bảng cho phép bạn viết một bộ mã duy nhất để xử lý tất cả các nhận xét.

Nhưng tôi bị rách. Nó là sạch hơn nếu bạn giữ chúng riêng biệt, miễn là bạn không bao giờ phải trộn hai loại bình luận trong cùng một danh sách (mà sẽ yêu cầu một UNION).

Answer 3

Kiểu thiết kế cá nhân của riêng tôi sẽ kết hợp chúng, sau đó thêm cờ nguyên để cho biết nhận xét là gì. Điều đó cũng sẽ cho tôi khả năng mở rộng trong trường hợp tôi muốn thêm sau này.

Answer 4

Nếu bạn kết hợp chúng sẽ làm hỏng cấu trúc khóa. Bạn sẽ phải có các khóa ngoài không có khả năng rỗng hoặc cấu trúc khóa "mềm" của khóa và loại. Tôi sẽ giữ chúng riêng biệt.