sql-server – 在类型/子类型设计模式中实现具有互斥子类的子类
|
>每个EntityType将拥有多少行(假设高于平均增长率,至少看看未来5年) 我认为我倾向于默认将E保留在单独的子类型表中,因为它至少是“更干净”.我会考虑将E移动到基类型表IF：大多数行不是用于C的EntityType;行数至少为数百万;并且我经常执行的查询需要E和/或从(D,E)上的索引受益的查询要么非常频繁地执行和/或需要足够的系统资源,以使索引减少整体资源利用率,或至少防止资源消耗的激增超过可接受的水平或持续足够长的时间以导致过度阻塞和/或死锁增加. UPDATE O.P. commented on this answer：
这种变化特别重要,因为它正是我所预测的可能发生在上面(第6个要点)的“在基类和A& B之间的中间表的归一化E”部分的“CONs”子部分中.具体问题是当这种变化发生时(并且它们总是如此)重构数据模型是多么容易/困难.有些人会争辩说任何数据模型都可以重构/改变,所以从理想开始.但是,虽然在技术层面上确实可以重构任何东西,但情况的实际情况是规模问题. 资源不是无限的,不仅仅是CPU /磁盘/ RAM,还有开发资源：时间和金钱.企业不断设定项目的优先级,因为这些资源非常有限.并且经常(至少在我的经验中),提高效率的项目(甚至系统性能以及更快的开发/更少的错误)优先于增加功能的项目.虽然这对我们技术人员来说是令人沮丧的,因为我们了解重构项目的长期利益是什么,但技术性较差的业务人员更容易看到新功能与新功能之间的直接关系,这只是业务的本质.收入.这可以归结为：“我们将在稍后回来解决这个问题”==“这个问题可能会在接下来的5 – 10年内出现,因为我们几乎总会有更重要的事情需要解决(具有讽刺意味的是,如由于我们尚未修复它而不断出现的支持案例)“. 考虑到这一点,如果数据的大小足够小,以便可以进行非常查询的更改,和/或您有一个足够长的维护窗口,不仅可以进行更改,还可以在发生变化时回滚错误,然后将E标准化为基类表和A& A之间的中间表. B子类表可以工作(尽管这仍然使您不必直接了解基类表中的特定类型(A或B)).但是,如果这些表中有数亿行,并且有大量代码引用这些表(在进行更改时必须进行测试的代码),那么通常比理想主义更实用.这是我多年来不得不面对的环境：9.87亿行&基类表中的615 GB,分布在18个服务器上.这么多代码击中了这些表(基类和子类表),存在很多阻力 – 主要来自管理层,但有时来自团队的其他成员 – 由于开发量的大小而进行任何更改需要分配的QA资源. 因此,再次,“最佳”方法只能逐个确定：您需要了解您的系统(即数据有多少,表格和代码如何相关),如何完成重构,以及人员您与之合作(您的团队和可能的管理层 – 您是否可以获得他们对此类项目的支持？).有一些变化,我一直在提及并计划1 – 2年,并采取多次冲刺/发布,以实现其中85％的实施.但如果你只有< 100万行,而不是很多代码绑定到这些表,那么你可能会开始更理想/“纯粹”的事情. 请记住,无论您选择哪种方式,至少应该注意该模型在未来两年的工作方式(如果可能的话).注意什么起作用,什么引起疼痛,即使它看起来像当时最好的想法(这意味着你也需要让自己接受搞砸 – 我们都这样做 – 这样你就可以诚实地评估痛点).并注意为什么某些决定有效或没有,以便您可以做出下次更有可能“更好”的决策:-). （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
