Sql 发票和交易设计

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

这些是我心目中的选择，你认为有哪些优点和缺点

发票实体本身并不持有金额，而是持有一个虚拟列表，其中包含与发票相关的所有交易，并且通过这些交易计算和显示金额。InvoiceId作为外键。 发票实体确实将金额和交易列表作为我假设的安全保险保存，但仍然将InvoiceId作为外键。 交易实体不包含外键。相反，金额是根据交易记录计算并存储在发票表中。与其他一些参考相应的发票。 目前我正在使用选项1。但是当我考虑未来时，我意识到我的事务表将包含很多事务。在某个时候，我可能想移动它们以提高性能，而不必移动或删除发票表。所以我会选择3号。但是，还有其他更可取的选项吗？

选项4

考虑到你的设置，我会在这里使用三个表的设置…让我们摆脱整个更新的想法。让我们拿两个基表…您将有数据字段，这只是名称和ID

Invoice Table
-InvoiceID

Transaction table
-TransactionID

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

 InvocieTransactions
-InvTransID
-InvoiceID
-TransactionID

现在，当您进行开票时，您只需在此表中进行插入，而不是进行更新……插入操作可以通过一条select语句完成，该语句将捕获所有交易并将其与新的发票ID关联

我添加了ITID作为此表的唯一标识符…这是可选的，但我喜欢在表上有唯一的编号，这样您将来可以引用一行，主要是为了解决问题，或者可能添加新的报告层

---

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

1是我的首选项…在您按客户分组发票的任何内容上添加索引？如果需要，解决速度问题。作为后一种选择…通常更重的负载是由事后报告引起的。研究如何创建聚合表和每晚从Prod环境加载报表服务器的ETL过程。谢谢。但是想象一下。我的事务表中有数百万行。当我生成发票时，对于每个用户，我在一定时间内循环处理事务，对于每个事务，我设置外键。这就是我所担心的性能问题。发票每月生成一次，交易每天创建一次。不要使用循环：如果你要做数百万条记录，循环应该是你最不想做的事情。SQL是基于设置的，一个脚本一次执行所有行。嗯，好的，那么您的意思是一个触发器，以便在创建新发票插入时，它将继续并使用插入的.InvoiceId一次性更新所有事务？这就是基于集合的意思吗触发器也倾向于一次处理一行……但这取决于生成发票时的需求。将几乎任何其他计算机语言都看作步骤1、步骤2、步骤3，对每行重复所有步骤。将sql视为所有行的步骤1，所有行的步骤2，所有行的步骤3，完成。在某个日期段内进行所有交易，并在一个脚本中生成所有发票。实际上，我很难理解更新发票id是什么意思……您在事务表中有invoiceID，生成invoiceID后您更新了事务？这很有意义。这可能是一个很好的解决方案。只需要想想它是否会影响我的交易机制的其他方面，但它不应该！谢谢我将以此为基础。一个问题，InvTransID字段不是唯一的标识符吗？是的……它不需要存在，但我喜欢它……如果以后出现问题，将唯一的编号与每个InvoiceTransaction记录关联将有所帮助。记住，当你在百万行操作时，要尽量避免更新…这实际上是旧的删除和新的插入。只插入一个就可以节省时间。对不起，我不清楚。我更多的是指为什么我应该有两个唯一的标识符？你说ITID是一个可选的唯一项，但是我可以用InvTransID来代替？啊，我错了……我在表上放了两个唯一键，但忘记了InvoiceID。哈Edditing答案…INVTranID适用于唯一标识。您将在invoicetransaction表中同时需要Trans_ID和Invoice_ID