用户要求非规范化数据库

Question

我处于开发数据库驱动系统的早期阶段，系统的最大部分围绕着继承类型的关系。有一个包含大约10列的父实体，并且将有大约10个从父级继承的子实体。每个子实体将有大约10列。我认为为父实体提供自己的表并为每个子项提供自己的表 - 每个子类的表结构是有意义的。

今天，我的用户要求查看我创建的系统的结构。他们对每子类表结构的想法犹豫不决。他们更喜欢一个大~100列表，因为它们更容易执行自己的自定义查询。

我是否应该考虑为用户而对数据库进行非规范化？

Answer 1

绝对不是。您以后可以随时创建一个视图，向他们展示他们想要看到的内容。

Answer 2

他们实际上是在要求报告。

您可以授予他们访问视图的权限，其中包含他们需要的所有字段...这样您就不会弄乱数据模型。

Answer 3

没有。正确构造数据，如果用户需要数据的非规范化视图，则将其创建为数据库中的VIEW。

或者，考虑一下RDBMS可能不适合此项目的存储工具。

Answer 4

出于某种原因，他们是用户而不是系统的程序员。为他们的查询提供单独的界面。像这样的超级用户既有帮助又有待处理。只需解释一下你需要以某种方式设计数据库，这样你才能完成你的工作。一旦完成，您将提供其他方法使查询更容易。

Answer 5

他们知道什么！？您可能会认为用户甚至不应该首先直接访问数据库。

这样做会让您面临巨大的性能问题，因为有几个用户正在运行荒谬的查询。

Answer 6

如果您在保持正确规范化的表格的同时以用户所需的格式创建了VIEW，那该怎么样？

Answer 7

除了支持或反对用户提议的许多技术原因之外，您需要在同一页面上传达各种风险和（更重要的）成本这些后果的后果。如果用户是您的客户并且他们付钱给您工作，请说明他们的糟糕“提议”的想法可能会花费他们更多的资金用于开发时间，额外的硬件资源等。

希望您能够以这样的方式解释它，以便展示您的专业知识以及为什么您的想法从长远来看对您的用户来说更有价值。

Answer 8

正如每个人或多或少都提到的那样，这种方式就是疯狂，你总能建立一个观点。

如果你不能让他们在这一点上出现，请考虑向他们展示这个帖子以及那些称他们说用户正在干涉他们不完全理解的事情的专业人员的数量，以及影响将是一个破坏的基础。

开发人员的工艺中很大一部分是对长期无效的感觉，而规范化规则在这方面几乎是规范的。在某些情况下，您需要进行非规范化（数据仓库等），但这听起来不像其中之一！

听起来好像你手上还有一个特别麻烦的用户品牌 - 认为只要他们有时间，他们认为自己可以更好地完成工作。这可能会有所帮助，也可能没有帮助，但我发现这些类型对演示有很好的反应 - 现在我已经发现，如果我穿着锋利并且在我的个性中表现出一点力量，它会让他们感觉像我是专家，在开始之前就可以防止一堆问题。

Answer 9

我强烈建议您提供一个答案，该答案不涉及针对您的数据库运行直接报告的人。一旦发生这种情况，您的数据库结构就会陷入困境，您基本上可以将其视为遗产。

视图是一个良好的开端，但稍后您可能希望将其构建为导出，以进一步分离。当然，那时你会遇到想要“实时”数据的人。适当的业务分析通常表明这是不必要的。实际的实时要求不能通过报告系统得到最佳处理。

要明确一点：我个人赞成每个子类的方法，但我不认为它实际上是直接报告关闭事务表的问题。

Answer 10

我会选择一个视图（正如其他人建议的那样）或内联表值函数（这样做的好处是你需要参数 - 比如日期范围或客户帐户 - 这可以帮助阻止用户查询对问题空间的任何限制）首先。内联TVF实际上是一个参数化视图，就引擎如何处理它们而言，它远比一个多语句表值函数或标量函数更接近视图，它可以表现得非常糟糕。

但是，在某些情况下，如果视图复杂或密集，则会影响生产性能。由于写入不当的临时用户查询，它还可能导致锁定持续时间更长或进一步升级，而不是更好的构建查询。在存在多对一或多对多关系的情况下，用户也可能错误解释E-R数据模型并产生乘法数字。下一个选项可能是使用索引或制作表格来实现这些视图并使其更新，这使我们更接近我的下一个选项...

因此，考虑到视图选项的这些缺点并且已经考虑通过开始制作数据副本来减轻它，我考虑的下一个选项是对这些数据的单独只读（对于这些用户）版本结构不同。通常，我会首先看一下Kimball风格的星型模式。您不需要拥有一个完整的时间一致的数据仓库。当然，这是一个选项，但您可以简单地使报告模型与数据保持同步。星型图是一种特殊形式的非规范化，特别适用于数值报告，并且一个给定的星不应该被用户意外滥用。您可以通过多种方式使星形更新，包括触发器，预定作业等。它们可以非常快速地报告需求并在相同的生产安装上运行 - 如果不是单独的数据库，可能在单独的实例上运行。

虽然这样的解决方案可能要求您有效地将存储要求提高一倍以上，但与其他实践相比，如果您能够很好地理解数据并且不介意拥有两个模型（一个用于交易和模型），这可能是一个非常好的选择。一个用于分析（请注意，无论如何，您已经开始使用最简单的第一个视图选项进行逻辑分离。）

一些架构师经常将服务器加倍并使用SAME模型进行某种复制，以便提供索引更严重或不同的索引服务器。这样的第二台服务器不会影响具有报告要求的生产交易，并且可以相当容易地保持最新。只有一个模型，但当然，这具有相同的可用性问题，只允许用户临时访问底层模型，而不会影响性能，因为他们有自己的游乐场。

这些猫皮肤有很多种方法。祝你好运。

Answer 11

客户永远是对的。但是，当您将需求转换为美元和美分时，客户可能会退缩。 100列表将需要额外开发时间来编写代码，该代码执行数据库将通过正确实现自动执行的操作。此外，他们的支持成本会更高，因为更多的代码意味着更多的问题和更低的调试容易性。

Answer 12

我将在这里扮演魔鬼的拥护者，并说两种解决方案听起来都像是对实际数据的不良近似。有一个原因是面向对象的编程语言不倾向于用这些数据模型中的任何一个来实现，并不是因为Codd 1970年关于关系的想法是存储和查询面向对象数据结构的理想系统。 ： - ）

请记住，SQL最初是作为用户界面语言设计的（这就是为什么它看起来像英语一样模糊，完全不像那个时代的其他语言：Algol，C，APL，Prolog）。我之前听说没有向用户公开SQL数据库的唯一原因是安全性（它们可能会取消服务器！）和可用性（谁可以在点击clicky时编写SQL？），但是如果它是他们的服务器并且他们我想，为什么不让他们？

鉴于“系统的最大部分围绕一种继承类型的关系”，我认真考虑一个允许我本地表示的数据库，Postgres（如果SQL很重要）或者本机对象数据库（如果您不需要SQL兼容性，那么它们很棒）。

最后，请记住，每个工程决策都是权衡。通过“坚持你的枪”（正如其他人提出的那样），你隐含地说用户欲望的价值是零。不要求SO正确回答这个问题，因为我们不知道您的用户想要对您的数据做什么（甚至不知道您的数据是什么，或者您的用户是谁）。告诉他们为什么你需要一个多表解决方案，然后找出一个你们都可以接受的解决方案。

Answer 13

您已实施Class Table Inheritance，他们要求Single Table Inheritance。两种设计在某些情况下都有效。

您可能希望获得Martin Fowler Patterns of Enterprise Application Architecture的副本，以了解有关每种设计的优缺点的更多信息。无论如何，这本书是你书架上的经典参考书。