当两个表非常相似时,什么时候应该将它们合并?
我有事件和照片,然后对两者进行评论。现在,我有两个评论表,一个用于与事件相关的评论,另一个用于照片评论。架构与此类似:
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)
结构之间真的有性能差异吗?对我来说,这似乎有点偏好。我确实看到了第二个模式的好处,如果我想为事件评论或照片评论添加一些特殊性,我有一个单独的表来执行此操作,如果我希望两者共享一个新属性,则有一个表可以添加新属性。
I have events and photos, and then comments for both. Right now, I have two comments tables, one for comments related to the events, and another for photo comments. Schema is similar to this:
CREATE TABLE EventComments
(
CommentId int,
EventId int,
Comment NVarChar(250),
DateSubmitted datetime
)
CREATE TABLE PhotoComments
(
CommentId int,
PhotoId int,
Comment NVarChar(250),
DateSubmitted datetime
)
My questions is whether or not I should combine them, and add a separate cross reference table, but I can't think of a way to do it properly. I think this should be OK, what are your thoughts?
Edit
Based on Walter's answer (and some light reading), I've come up with this:
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)
Are there really any performance differences between the structures? To me, it seems like a bit a preference. I do see the benefits in the second schema, if I want to add some specificity to event comments or photo comments, I have a separate table to do so, and if I want both to share a new property, there is a single table to add the new property.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
评论、照片评论和事件评论以一种称为“泛化专业化”的模式相关。这种模式是通过面向对象语言中的简单继承来处理的。设置捕获相同模式的表模式有点复杂。
但这很好理解。在谷歌上快速搜索“泛化专业化关系建模”将为您提供几篇关于该主题的好文章。
Comments, PhotoComments, and EventComments are related in a pattern called "generalization specialization". This pattern is handled by simple inheritance in object oriented languages. It's a little more intricate to set up a schema of tables that will capture the same pattern.
But it's well understood. A quick google search on "generalization specialization relational modeling" will give you several good articles on the subject.
如果你把它们结合起来,就会弄乱关键结构。您必须拥有可为空的外键或键和类型的“软”键结构。我会把它们分开。
If you combine them it's going to mess up the key structure. You will have to have null-able foreign keys or a "soft" key structure of key and type. I'd keep them separate.
您可以将它们组合起来并添加一个字段来指示它是用于照片还是事件。
您将需要两个外键;一个用于照片,一个用于事件,但是将它们放在一个表中可以让您编写一组代码来处理所有评论。
但我很伤心。如果您将它们分开,那么它会更干净,前提是您不必在同一列表中混合两种注释类型(这将需要 UNION)。
You can combine them and add a field that indicates whether it's for a photo or an event.
You will need two foreign keys; one for photos and one for events, but having them in one table allows you to write a single set of code to handle all comments.
But I'm torn. It is cleaner if you keep them separate, provided you never have to mix the two comment types in the same list (which would require a UNION).
我自己的个人设计风格是将它们组合起来,然后添加一个整数标志来告诉注释的用途。如果我以后想添加更多内容,这也将为我提供可扩展性。
My own personal design style would be to combine them, then add an integer flag to tell what the comment is for. That would also give me scalability in case I want to add more later.