要求非规范化数据库的用户

Posted 2023-03-08

【中文标题】要求非规范化数据库的用户

【英文标题】：Users asking for denormalized database

【发布时间】：2010-12-16 08:42:08

【问题描述】：

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

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

为了用户，我应该考虑对数据库进行非规范化吗？

【问题讨论】：

您能否再详细说明一下您的数据库结构？我将在这里逆流而上，描述一种可能有用的情况，但我需要了解结构。

将底层对象暴露给最终用户时有一个危险的词。虽然在这种情况下视图是最佳的，但用户不应该看到原始数据。当然，我可以被认为是一个现存的程序员，他认为最终用户只会把这些类型的事情搞砸。 :)

@bogertron：existest = 精英。在发表评论之前，我真的应该开始使用 word。

自信。告诉他们去远足。告诉他们如果他们不知道如何进行 JOIN，他们将获得 CSV 导出的接口（或者，如果您的数据库支持 VIEW）。不要让他们搞砸你正在开发的平台，反正他们以后只会讨厌你。

Excel 是结构化数据的敌人。只是说'

【参考方案1】：

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

【讨论】：

我遇到了一些编程情况，我不得不解决某人在应用户要求修改表时造成的混乱，当我说你在做你自己和未来时，请相信我当您将数据库设置为适合应用程序并设置视图供他们查询时，开发人员会有所帮助。如果可以的话 +5！

如果您的用户要使用复杂的查询进行大量报告，您可能需要考虑交易系统的仓库提取。这样就不会互相打扰了。

如果您还没有熟练使用 UNION，您会想要精通。

【参考方案2】：

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

您可以让他们访问包含他们需要的所有字段的视图...这样您就不会弄乱您的数据模型。

【参考方案3】：

如果您以用户想要的格式创建 VIEW，同时仍保持正确的规范化表，会怎样？

【讨论】：

虽然这不是这里的最佳答案，但我投票赞成它以清晰简洁地表达潜在的解决方案。

【参考方案4】：

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

或者，考虑到 RDBMS 可能不是该项目的合适存储工具。

【讨论】：

我曾考虑过建议我的雇主启动一个面向对象的数据库，但这需要与我公司的一位 DBA 协调，他已经承受着巨大的工作量。 OODB 是否有行业标准？

我对 OODB 了解不多，但不，我不相信数据库或查询数据库都有标准。各种产品提供各种或多或少的“类似 SQL”的语法。您还可以查看一个确实存在标准查询语言的 XML 数据库，尽管似乎很少有人能够掌握甚至理解它。

【参考方案5】：

出于某种原因，他们是系统的用户而不是程序员。为他们的查询提供单独的界面。像这样的高级用户既可以提供帮助，也可以让人很痛苦。只需说明您需要以某种方式设计数据库，这样您就可以完成您的工作。一旦完成，您就可以提供其他方法来简化查询。

【参考方案6】：

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

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

【讨论】：

我认为当他说“用户”时，他真正的意思是“客户”。

本例中的差异相同。如果他们将在此 DB 之上使用应用程序，则他们是 用户。

【参考方案7】：

我强烈建议提出一个不涉及针对您的数据库运行直接报告的答案。发生这种情况的那一刻，您的数据库结构就一成不变，您基本上可以认为它是遗留的。

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

要明确一点：我个人更喜欢按子类表的方法，但我认为这实际上并不像直接报告事务表那样大。

【参考方案8】：

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

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

【参考方案9】：

正如每个人或多或少提到的那样，这种方式很疯狂，你总是可以建立一个视图。

如果您无法让他们在这一点上回过神来，请考虑向他们展示此线程以及权衡说用户正在干预他们不完全理解的事情的专业人士的数量，以及影响将是一个被破坏的基础。

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

听起来您手上可能有一个特别令人不安的用户品牌——那些认为只要有时间自己就能更好地完成您的工作的业余开发人员。这可能有帮助，也可能没有帮助，但我发现这些类型的人对展示的反应很好——现在有几次我发现，如果我穿着得体并且在我的个性中表现出一点力量，这会让他们感觉像我是专家，可以在问题开始之前预防一堆问题。

【参考方案10】：

我会选择视图（正如其他人建议的那样）或内联表值函数（这样做的好处是您需要参数 - 例如日期范围或客户帐户 - 这可以帮助阻止用户在没有问题空间的任何限制）首先。内联 TVF 实际上是一个参数化视图，并且在引擎如何处理它们方面更接近于视图，而不是多语句表值函数或标量函数，后者的性能非常差。

但是，在某些情况下，如果视图复杂或密集，这可能会影响生产性能。对于编写不佳的临时用户查询，与构建更好的查询相比，它还可能导致锁持续时间更长或升级程度更高。在存在多对一或多对多关系的情况下，用户也可能会误解 E-R 数据模型并产生乘数。下一个选项可能是用索引实现这些视图或制作表格并保持更新，这让我们更接近我的下一个选项......

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

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

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

有很多方法可以给这些猫剥皮。祝你好运。

【参考方案11】：

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

【参考方案12】：

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

请记住，SQL 最初被设计为一种用户界面语言（这就是为什么它看起来有点像英语，而不像那个时代的其他语言：Algol、C、APL、Prolog）。我听说今天不向用户公开 SQL 数据库的唯一原因是安全性（他们可能会关闭服务器！）和可用性（当您可以点击时，谁愿意编写 SQL？），但如果是他们的服务器和他们想，那为什么不让他们呢？

鉴于“系统的最大部分围绕继承类型的关系”，那么我会认真考虑一个数据库，让我可以原生地表示它，Postgres（如果 SQL 很重要）或原生对象数据库（如果您不需要 SQL 兼容性，使用起来非常棒）。

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

【参考方案13】：

您已经实现了Class Table Inheritance，而他们正在请求Single Table Inheritance。这两种设计在某些情况下都是有效的。

您可能想要获取 Martin Fowler 的 Patterns of Enterprise Application Architecture 的副本，以详细了解每种设计的优缺点。无论如何，这本书是您书架上的经典参考书。