发票和交易设计答案

【问题标题】：Invoice and transactions design发票和交易设计
【发布时间】：2014-02-11 11:29:42
【问题描述】：

我目前正在考虑如何设计我的发票实体。特别是涉及发票金额时。

这些是我想到的选项，你觉得有什么好处和坏处？

目前我正在使用选项 1。但是当我考虑未来时，我意识到我的交易表将包含很多交易。在某些时候，我可能想移动它们以提高性能，而不必移动（删除）发票表。所以3号是我的选择。但是，还有其他更受欢迎的选择吗？

【问题讨论】：

#1 是我的偏好...在您按（客户？）对发票进行分组的任何内容上添加索引，以便在需要时解决速度问题。作为以后的选择...通常较重的负载是由事后报告引起的。研究创建聚合表和从 Prod 环境加载报告服务器的每晚 ETL 流程。
嗯，谢谢。但想象一下。我的交易表中有数百万行。当我生成发票时，对于每个用户，我都会在一定时期内遍历交易，并为每笔交易设置外键。这就是我担心性能方面的问题。每月生成一次发票，每天创建交易。
不要使用循环 :) 如果您正在处理数百万条记录，那么您最不想在此处添加循环。 SQL 是基于设置的，1 个脚本一次执行所有行。
嗯，好吧，所以您的意思是一个触发器，以便在创建（插入）新发票时，它会继续使用插入的 InvoiceId 更新所有交易？这就是基于集合的意思吗？ :)
触发器也倾向于一次处理一行......但这将取决于您在生成发票时的要求。将几乎任何其他计算机语言视为第 1 步、第 2 步、第 3 步，对每一行重复所有步骤。将 sql 视为所有行的第 1 步，所有行的第 2 步，所有行的第 3 步，完成。获取特定日期期间的所有交易并在一个脚本中生成所有发票。实际上，我很难理解更新发票 ID 的含义...您在交易表中有 invoiceID，并且在生成 invoiceID 后更新交易？

【解决方案1】：

选项 4？

鉴于您的设置，我会在这里设置三张桌子...让我们摆脱整个更新的想法。让我们使用 2 个基表...您将拥有数据字段，这只是名称和 ID。

Invoice Table
-InvoiceID

Transaction table
-TransactionID

注意到没有 invoiceID？我们将使用第三个表来控制该关系。

 InvocieTransactions
-InvTransID
-InvoiceID
-TransactionID

现在，当您开具发票时，您只是在此表中执行插入操作，而不是更新...并且该插入可以通过一个 select 语句完成，该语句获取所有交易并将其与您的新发票 ID 相关联。

我添加了 ITID 作为此表的唯一标识符...它是可选的，但我喜欢在表上使用唯一编号，以便您将来可以参考一行（主要用于故障排除，或者可能添加新的报告层）

有意义吗？如果您愿意，我们可以继续讨论这个问题

【讨论】：

这是有道理的。这可能是一个很好的解决方案。只需要考虑它是否会影响我的交易机制的其他方面，但它不应该！谢谢。我会以此为基础。
一个问题，InvTransID字段不是唯一标识符吗？
是的......它不需要在那里，但我喜欢拥有它......如果以后出现问题，为每个 InvoiceTransaction 记录关联一个唯一编号会有所帮助。记住在百万行级别操作时要尽量避免更新……这实际上是删除旧的并插入新的。只做一个插入将节省时间。
对不起，我不清楚。我更多的是指为什么我应该有两个唯一标识符？你说 ITID 是可选的唯一值，但话说回来，我可以使用 InvTransID 代替吗？
啊，我的错误....我在桌子上放了两个唯一的键并忘记了 InvoiceID。哈。编辑答案...InvTransID 适合唯一身份。您需要在 invoicetransaction 表中同时包含 Trans_ID 和 Invocie_ID