对于那些在金融部门，存储数据的问题

Question

我正在创建将用户财务信息存储在sqlite数据库中的应用程序。我希望它能存储各种信息，如账号，银行名称，利率等。

我想问一下如何在真实的财务软件中完成以下操作。作为一个例子，当有人通过软件从数据库请求数据时，软件是否只是去检索数据，或软件是否获取基本信息，然后在现场计算所需的数据。

如果我们想查看付款金额并且我们知道这是一定百分比，我们是否将付款金额存储在表格中，或者我们只是当场计算。

如果我想查询数据库的总应计利息，我是将这些数据存储在表格中还是我现场计算。

我只是难以理解是否更好地保持数据库表简单并在现场进行大多数计算，或者在表上保留更多数据并让软件在后台填充它。

Answer 1

通常，在所有行业中，我们都不会存储可以计算的数据，否则会违反数据库常规表单。如果一条数据得到更新，它们都必须得到更新。

但要小心，因为最初可能会计算数据，但可能不会随其他数据而改变。

就像可能存在当前的利率一样，但是在给予利息支付时，您​​可能希望存储他们赚取的利率，因为他们赚取的利率是不变的，但目前的利率不是。

Answer 2

“Immutable Invoices”在某种程度上会引起关于这个问题的警示。虽然人们可能不想存储额外的数据，但有些记录可能最好导出到某些存档中，以防价格变动等不应追溯更改发票的情况。

Answer 3

我为银行编写财务软件。

我不能说完全正确的答案是什么，但这就是我所看到的和有效的。

根据计算的复杂程度（.5s或2小时/记录），代码可以在从数据库查询时动态计算结果，也可以从另一个表中获取已计算的结果。如果需要回溯结果，则分别存储计算中的所有变量非常有用。

在许多情况下，计算包括实时费率和财务信息，并且没有时间（计算复杂时）用正确计算的结果更新所有记录。这些通常是隔夜批次，但缺乏实时更新。

Answer 4

嗯，请记住，您需要记录与费率变化相关的大量历史记录，并将您的个人财务条目与潜在的许多不同费率相关联。如果需要，我们保持从头开始生成所有计算的能力（并定期协调），但通常我们有定期更新的历史聚合位置（每周或每月的新条目），并且计算基于自它们以来的更改。在瞬间从头开始生成所有东西并不总是切实可行。

Answer 5

Usualy（显然并非总是如此），在处理财务数据时，您会在几乎所有ERP中找到某种预先获取的计算数据。当你必须移动数百万的交易并且你必须制作大量的计算列和聚合时，存储和保存这些数据的好处将是有益的。您可以在原始数据所在的表中找到此数据作为aditional列，或者在存储聚合或中间操作的单独表中找到此数据。

Answer 6

在财务应用程序中，数据字段通常以某些标准格式打包。这些数据字段携带用户认证数据。打包数据命中到获取服务器，作为响应，生成响应代码。响应数据打包成标准格式并发送到客户端，客户端定义的代码应与成功事务的响应代码匹配。通过这种方式，工作继续在财务软件中进行。