数据库设计中的共享目的表(如何*实现问答设施)

我一直认为,涉及共享表目的数据库的设计有点像臭代码的特征,并且逐渐增加了与臭代码相关的问题.

我的意思是,人们过度规范化,使用1个表,其中2个表可能更符合逻辑,人们刚刚发现了规范化并且过度使用它们以至于他们虚拟地将数据库分层在数据库上,或者尝试使用天真地分层数据来解决他们所有的问题.

问题是,当你有2组数据看起来是相同的,但它们有不同的用途时,你是否使用相同的表来表示它？你什么时候知道什么时候使用它是一个好主意和坏主意？

我一直认为,在同一查询中使用两次表格的不必要的自引用表或结构在设计,长期性能和未来改进的容易性方面都是一个非常危险的困境.

那当然是,直到我在这里看到RSS提要中的一两件事.现在我不会就SO如何运作进行元讨论,但这里似乎有一个隐含的设计考虑因素挑战了我的想法,并希望在这种逻辑风格上收集更具凝聚力的答案.

您会注意到通用问题的格式如下:

 /question/1234/stuff-here-that-s-safe-to-leave-out

我一般认为这意味着问题在某处被数字排序.

但这就是困扰我的问题:我将以问题316210为例.如果您查看此问题的RSS订阅源,您会注意到该问题有一个条目,以及一系列答案条目,这些条目在功能上与问题条目完全相同,除了一些细微差别.现在注释在答案条目中也有链接引用,...到问题,但不是同一个问题,但是对于不同的问题,例如问题316218,当访问时,将您重定向回原始问题.

现在我对他们如何在代码中实现它感兴趣,问题是你在这里,问题和答案似乎是共享同一个表(因此顺序问题ID),当用户引用答案ID时,你必须首先查询数据库,然后去"嘿!,哎呀!,这不是一个问题!" 然后继续进行第二次查询以查找该问题的父级(在同一个表中),然后将您重定向到实际的问题页面,更不用说自我加入查询所需的所有喧嚣(我一直认为肮脏的)和整个地方的条件调整行为.

少挖掘,真正的问题

问题是,这里有2组数据共享同一个表,当然,至少现在这个数据在表面上是相似的,但看起来有很多技术债务涉及.

长期考虑涉及实现可以应用于问题而不是答案的新功能,反之亦然,更不用说避免在一些不起眼的角落中将其解释为另一个.您无法在一个应用程序集中添加新列,而无需在另一个应用程序集中考虑结果效果.

当然,也有从使用的单台未成年人利益,当你是正在制作所方面,你只需要一次代码之间共享的功能,但是这可以通过使用一个父类的常用方法很容易地进行表示,绑定到不同情况的特定表的子类和子类.因此,至少在这种情况下,添加新功能对其他方案没有后续影响.

现在我在很多地方遇到过这种问题,当然,但是SO是最容易指出的例子.

当您像这样实现数据库时,您是否共享该表,还是分叉？

什么时候,为什么？