'属于'db关系最佳实践？

Question

我正在拍摄一个摄影网站.网站上的照片将始终属于一个事件.我最初的设计是:

Table: Events
ID, Title, etc

Table: Photos
ID, ThumbnailURL, etc

Table: EventPhotos
EventID, PhotoID, SortOrder

这对我来说似乎很自然,但我意识到它描述的关系实际上允许照片属于许多事件.我想过像这样重构它,它只允许照片属于一个事件:

Table: Events
ID, Title, etc

Table: Photos
ID, EventID, SortOrder, ThumbnailURL, etc

事件关系数据在照片表中 - 原始设计将照片,事件和关系分开 - 对我来说似乎有点肮脏/混乱 - 但它确实避免了连接,并且它强制关系到'has一个/属于'而不是'有很多' - 您怎么看？

Answer 1

对于一对多的关系,你的第二次采取是标准的,正常的,正确的做法.

但是,您是否完全确定您在第一次拍摄中描绘的多对多关系不适用？我不会那么肯定,但你比我更了解你的领域.

编辑:

OP发表评论;

谢谢.我真的不相信照片应该属于多个事件 - 事件是照片拍摄,每张照片都是根据某个拍摄的定义,并且按事件查看是浏览网站的唯一方式.我非常有信心一对多是正确的.

该评论有几个课程,所以我想编辑它以强调这些课程.

观察1.最重要的是,如果不了解两件事,就无法对模式进行建模:建模的真正问题域,以及我们的解决方案对模型的要求.

我最初的猜测是OP的事件和图片是在事件中模拟照片的显示,如在艺术画廊(或网站上的图片库).在这种情况下,例如,安塞尔·亚当斯在线画廊可能会有很多活动,其中显示的是安塞尔·亚当斯的照片,标题为"亚当斯的成熟作品","亚当斯的结构照片"或"亚当斯的沙漠照片".所有三个事件都可能包括亚当的"莫哈维沙漠中的传输线",1941年.由于许多照片可以在很多事件中展示,我们需要一个多对多的结构.

但OP的"事件"是拍摄照片,显然,正如OP所说,任何一张照片都是在一张照片中拍摄的.

这里的教训是,在我们知道问题域之前,我们无法建模(或只能临时建模).

我还建议改变表名"事件",以使这一点显而易见.将其称为"拍摄"或"photo_shoot"可以更清楚地了解我们的建模.

观察2. OP的评论为他的反对提供了一个答案,即在照片中发生事件FK是"混乱的".OP非常敏锐地意识到这"确实避免了加入,并且它强制关系到'有一个/属于'而不是'有很多'".(避免连接是一个实现问题,正确的关系更为基础,因为它是一个建模问题.)

他应该意识到的是,在我们的解决方案和问题领域中,询问一张照片是有意义的,"在这张照片拍摄的照片会话/活动中".这就是为什么它并不凌乱:"在哪个会话中采用'是关于照片的合法问题或属性,而FK提供了该问题的答案.这也意味着在这种情况下,从照片到事件的FK应该是'可以为空:照片必须有照片会话,否则可能没有照片.

(这里还有一些额外的课程,关于如何建立一对多的关系或多对多的关系,以及让FK可以为空的意义是什么意思;我会把它们带到下一次.)