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

绝对不是。以后您总是可以创建一个视图来显示他们想要看到的内容。

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

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

不。正确地构造数据,如果用户需要数据的非规范化视图,请将其创建为数据库中的视图。

或者,考虑到RDBMS可能不是此项目的适当存储工具。

出于某种原因,他们是系统的用户而不是程序员。为他们的查询提供单独的接口。像这样的超级用户既有帮助,又很难应付。只需解释一下你需要以某种方式设计数据库,这样你就可以完成你的工作,句号。一旦完成,您就可以提供其他方法来简化查询。

他们知道什么!你可以这么说 用户 一开始就不应该直接访问数据库。

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

如果您以用户想要的格式创建了一个视图,同时仍然维护一个适当规范化的表,那该怎么办?

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

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

正如每个人或多或少提到的那样,这就是疯狂,你可以建立一个观点。

如果你不能让他们在这一点上走来走去,考虑向他们展示这条线索和赞成的人的数量,他们说用户在干预他们不完全理解的事情,而这种影响将是一个被破坏的基础。

开发人员的工作中很大一部分是对长期无法解决的问题的感觉,在这方面,规范化规则几乎是规范的。在某些情况下,您需要取消规范化(数据仓库等),但这听起来不像是其中之一!

听起来你的手上可能有一个特别麻烦的用户品牌——一个业余的开发者,他认为只要他们有时间,他们就能更好地完成你的工作。这可能有帮助,也可能没有帮助,但我发现这些类型的人对演讲反应很好——有几次我发现,如果我穿得很利落,在我的个性中表现出一点力量,这会帮助他们感觉我是一个专家,在他们开始之前防止一系列问题。

我强烈建议您提出一个不涉及对您的数据库运行直接报告的答案。一旦发生这种情况,您的数据库结构就被设置成了石头,您基本上可以考虑它是遗留的。

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

只是要明确一点:我个人倾向于按子类方法使用表,但我认为它实际上并不像直接报告事务表那样重要。

我会首先选择一个视图(如其他人所建议的)或一个内联表值函数(其好处是您需要参数——比如日期范围或客户帐户——这有助于阻止用户在没有任何问题空间限制的情况下进行查询)。内联TVF实际上是一个参数化视图,与多语句表值函数或标量函数相比,在引擎如何处理这些视图方面,它更接近于该视图,因为后者的性能非常差。

但是,在某些情况下,如果视图复杂或密集,这可能会影响生产性能。对于编写得不好的即席用户查询,它还可能导致锁的持续时间更长,或者升级得比构建得更好的查询更长。在存在多对一或多对多关系的情况下,用户也有可能误解E-R数据模型并产生乘法。下一个选项可能是用索引实现这些视图,或者使表保持更新,这使我们更接近我的下一个选项…

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

尽管这样的解决方案可能需要您有效地将存储需求提高一倍以上,但与其他实践相比,如果您很好地了解数据,并且不介意有两个模型,一个用于事务,另一个用于分析,这可能是一个很好的选择(请注意,您已经开始进行这种逻辑分离了,任何情况下使用最简单的第一个视图选项)。

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

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

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

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

请记住,SQL最初是作为一种用户界面语言设计的(这就是为什么它看起来像英语,一点也不像那个时代的其他语言:algol、c、apl、prolog)。我听说今天不向用户公开SQL数据库的唯一原因是安全性(他们可能会关闭服务器!)以及可用性(当你可以点击的时候谁想写SQL?)但是如果是他们的服务器,他们想要,那为什么不让他们呢?

考虑到“系统的最大部分围绕着继承类型的关系”,那么我会认真考虑一个数据库,它允许我以本机方式表示这种关系,或者 Postgres (如果SQL很重要)或本机对象数据库(如果您不需要SQL兼容性,那么可以使用它)。

最后,记住每个工程决策都是一个权衡。通过“坚持你的枪”(正如其他人所提议的那样),你暗示着你的用户的欲望是零。不要这样要求正确的答案,因为我们不知道您的用户希望如何处理您的数据(甚至不知道您的数据是什么,也不知道您的用户是谁)。去告诉他们为什么你想要一个多表的解决方案,然后和他们一起制定一个你们都能接受的解决方案。

你已经实现了 Class Table Inheritance 他们要求 Single Table Inheritance . 两种设计在某些情况下都有效。

你可能想要一份马丁·福勒的 Patterns of Enterprise Application Architecture 更多了解每种设计的优点和缺点。无论如何,那本书是你书架上的经典参考书。