sql - 何时对数据库设计进行非规范化

Question

我知道在 Stack Overflow 上已经广泛讨论了规范化。我已经阅读了许多以前的讨论。不过，我还有一些其他问题。
我正在使用至少有 100 个表的旧系统。数据库具有一些未规范化的结构、包含各种不同数据的表以及其他问题。我被赋予了尝试改进它的任务。我不能只是重新开始，而是需要修改现有的架构。
过去我一直试图设计规范化的数据库。现在的问题。一位资深开发人员建议，在某些情况下我们无法正常化:

使用时态数据。例如，创建链接到产品的发票。如果客户在一年后要求提供此发票的副本，我们必须能够提供原件的准确副本。如果产品价格、名称或描述已更新怎么办？大佬建议把价格等产品信息复制到发票表中。我想也许我们应该有另一个表，例如具有日期字段的 productPrice ，以便我们可以跟踪价格随时间的变化。我猜我们需要相同的产品描述和名称？看起来很复杂。你怎么认为？

数据库是一个会计系统。我对会计不是很熟悉。目前，一些汇总数据被导出并存储在数据库中。例如当年的总销售额。我的高级助理曾说过，会计师喜欢通过将此值与从发票等实际计算的数据进行比较来检查事情是否正确，以使他们确信应用程序正常工作。

他说，目前我们可以判断是否有人错误地删除了去年的发票，因为总数不一样。他还指出，即时计算这些总数可能会很慢。当然我说过数据不应该被复制，应该总是在需要的时候计算。我建议我们可以使用 SQL Reporting Services 或其他一些可以在一夜之间生成这些报告并缓存它们的解决方案。反正他是不信的。对此有何评论？

Answer 1

您的高级同事是开发人员，而不是数据建模师。你最好从头开始，没有它们。规范化只对那些不会读书的人来说是复杂的。他让你思考是很公平的，但有些问题是荒谬的。

您的号码:

您需要了解实际在线数据和历史数据之间的差异；那么仅仅是历史需求和文件需求之间的区别。对于特定的业务需求，它们都是对的，对所有其他的都是错的，没有普遍的对与错。

为什么发票没有纸质副本？在大多数国家，这将是法律和税收要求，究竟有什么困难才能找出旧发票？

如果数据库要求存储已关闭的发票，那么当然，一旦发票关闭，您就需要一种捕获该信息的方法。

ProductPrice (实际上，我称之为 ProductDate )是个好主意，但可能没有必要。但是您说得对，您需要在整个数据库的完整上下文中评估数据的流通性。

我看不出将产品价格复制到发票表会有什么帮助(行项目不是很多吗？)

在现代数据库中，发票的副本需要反刍，关闭的发票另外以不同的形式存储，例如 XML。一位客户将 PDF 保存为 BLOB。因此，五年前的产品价格没有任何问题。但是基本的发票数据是在线的和最新的，即使是已关闭的发票；您只是无法使用当前价格重新计算古老的发票。

有些人使用archive_invoice 表，但这有问题，因为现在每个代码段或用户报告工具都必须查看两个地方(请注意，现在有些用户比大多数开发人员更了解数据库)

无论如何，这都是讨论，供您理解。

数据库从一组表(无“归档”表

发票一经创建，即为合法单据，不能更改或删除(可以冲销或部分记入新发票，具有负值)。它们被标记 IsIssued/IsPaid/Etc

Products不能删除，可以标记IsObsolete

InvoiceHeader 和 InvoiceItem 有单独的表

InvoiceItem两者都有 FK InvoiceHeader和 Product

出于多种原因(不仅是您提到的原因)，InvoiceItem 行包含 NumUnits; ProductPrice; TaxAmount; ExtendedPrice .当然，这看起来像是“非规范化”，但实际上并非如此，因为价格、税率等可能会发生变化。但更重要的是，法律要求我们可以按需复制旧发票。

(如果可以从纸质文件中复制，则不需要)

InvoiceTotalAmount是派生列，只是 SUM() InvoiceItems

那是垃圾。会计系统和会计师不会那样“工作”。

如果是真正的会计系统，那么就会有JournalEntries，或者说“复式”；这是(法律规定的)合格帐户必须使用的内容。

双重入境并不意味着重复入境；这意味着每笔金融交易(一笔金额)都应该有一个源账户和一个目标账户；所以没有“非规范化”或重复。在银行数据库中，由于金融交易针对单个账户，因此通常在一个 Db 交易中呈现为两个独立的金融交易(行)。普通的商业数据库约束用于确保每笔金融交易都有两个“面”。

确保发票不可删除是一个单独的问题，与安全性等有关。如果有人对从他们的数据库中删除的东西感到偏执，和 他们的数据库不是由合格的人保护的，那么他们有更多不同的问题，与这个问题无关。获得安全审计，然后按照他们的指示去做。

维基百科不是关于规范化的可靠信息来源。

规范化数据库总是比非规范化数据库快得多。因此，了解规范化和非规范化是什么以及不是什么非常重要。当人们有流动的和业余的“定义”时，这个过程会受到很大的阻碍，只会导致困惑和浪费时间的“讨论”。当你有固定的定义时，你可以避免所有这些，然后继续工作。

汇总表是很正常的，为了节省时间和处理能力，重新计算不会改变的信息，例如:每年但今年的 YTD 总数；今年每个月的 MTD 总计，但不是本月。当(a)信息非常大并且(b)没有改变时，“总是重新计算”数据有点愚蠢。仅计算当月

在银行系统中(每天数百万笔交易)，在 EndOfDay 时，我们也计算和存储每日总计。这些在过去 5 天被覆盖，因为审计员正在进行更改，并且允许针对过去 5 天的金融交易的 JournalEntries。

非银行系统一般不需要每日总计

汇总表不是“非规范化”(在那些刚刚从他们神奇的、不断变化的流动“来源”中了解“规范化”的人的眼中；或者作为非实践者，他们应用简单的非黑即白规则到一切)。同样，这里不讨论定义；它根本不适用于汇总表。

汇总表不影响数据完整性(当然假设它们的来源数据是完整的)。

汇总表是 另外到数据库，不需要与数据库具有相同的约束。与数据库表相反，本质上有报告表或数据仓库表。

没有与汇总表相关的更新异常(这是一个严格的定义)。您不能更改或删除去年的发票。更新异常适用于真正的非规范化或非规范化当前数据。