我有活动和照片,然后是两者的评论。现在,我有两个评论表,一个用于与事件相关的评论,另一个用于照片评论。架构类似于:
CREATE TABLE EventComments
(
CommentId int,
EventId int,
Comment NVarChar(250),
DateSubmitted datetime
)
CREATE TABLE PhotoComments
(
CommentId int,
PhotoId int,
Comment NVarChar(250),
DateSubmitted datetime
)
我的问题是我是否应该将它们组合起来,并添加一个单独的交叉引用表,但我想不出有办法正确地做到这一点。我认为这应该没问题,你有什么想法?
修改
根据沃尔特的回答(以及一些轻读),我想出了这个:
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)
结构之间是否存在任何性能差异?对我来说,这似乎有点偏好。我确实看到了第二个模式的好处,如果我想为事件评论或照片评论添加一些特异性,我有一个单独的表来做,如果我想要两者共享一个新属性,有一个表到添加新属性。
答案 0 :(得分:9)
评论,PhotoComments和EventComments以称为“泛化专业化”的模式相关。此模式由面向对象语言中的简单继承处理。设置一个可捕获相同模式的表模式会更复杂一些。
但它很好理解。快速谷歌搜索“泛化专业化关系建模”将给你几个关于这个主题的好文章。
答案 1 :(得分:4)
如果你把它们组合在一起就会弄乱关键结构。您必须具有可以为空的外键或键和类型的“软”键结构。我会将它们分开。
答案 2 :(得分:1)
您可以组合它们并添加一个字段,指示它是用于照片还是事件。
你需要两个外键;一个用于照片,一个用于事件,但将它们放在一个表中允许您编写一组代码来处理所有注释。
但是我被撕裂了。如果你将它们分开,那么它就更清晰了,只要你不必在同一个列表中混合两种注释类型(这需要一个UNION)。
答案 3 :(得分:1)
我自己的个人设计风格是将它们组合起来,然后添加一个整数标记来说明评论的内容。如果我想稍后添加更多内容,那么这也将为我提供可扩展性。