复式记账系统中与各州的高级交易
Ale*_*lex 7 accounting database-design relational-database
假设有一个复式记账系统：
我更喜欢后一种具有归一化的模型Transaction。
有许多状态长期运行的复杂操作。一笔大交易会影响许多分机。帐户（甚至许多分类帐），您可以反转（发布相反的Transactions），添加新交易（又名费用，罚款）或从所有涉及的分机重新分配资金。状态改变时的账户/账本交易。必须保留对这些特定于流程的表的引用Transactions，并且不要在其中重复Amount。
更多示例：
一个简单的例子ApplicationTransaction是Bet由几个 s 组成的，Pledge当您从每个参与者那里获取一些抵押品时。每个参与者甚至拥有不同的资产，并且House可以使用其中的许多资产来满足某些要求。我正在考虑ApplicationTransaction带有鉴别器的通用表D和许多特定的表。
以及带有引用其执行的许多复式记账事务的列的ApplicationTransaction表。State在其生命周期内，ApplicationTransaction它可以发布（make Transactions）其状态更改，但并非总是如此。例如，Bet获取抵押品并在时间到了时释放它Bet，在某些情况下，它会重新分配该操作持有的初始金额，但其某些状态不会发布。
A Lottery（这是这里最常见的用例）可能是ApplicationTransaction影响许多账户的一个例子，它以大量的“空投”奖金开始和结束。每个实例都有自己的属性值，属性是静态的。
另一个用例是Trade两个分机之间。House 可以作为中间人的帐户，必须从双方获取资产，将其转移到特殊的LedgerAccount|XYZ|AL|Escrow|，每个ApplicationTransaction.Type，而不是每个实例。保留与特定实例相关的传输记录Trade，可能会持续一段时间，有多种状态、属性、不同的结果。账户持有人可能会受到一侧的处罚并另一侧得到偿还。没有订单簿或撮合引擎。这种交换过程有几个状态，如果发生这种转变，另一个交易对手可能会参与争议解决State。Trade两个参与者都必须用类似的内容标记 a Payment Received（假设付款是在系统外部完成的）。这就是状态转换。系统可以向每个参与者收取费用。
这不是一个单一的Transaction条目。他们一群。例如，如果我需要将一些金额存入托管，我可以放入 X * 祖母绿和 X * 钻石来与公主约会。因此，它不仅发布了许多(AssetType, Amount, AccountNo)（N * 资产 * 2 方），而且还发布到Income LedgerAccount. 假设我们对一桶进行交易Assets。
还可以添加一些表来限制每个操作类型可能的转换，以便我们可以添加约束。我将其视为状态查找表的副本NextState，其本身具有额外的列引用，这样它定义了一组可用状态。不过超出了这个问题的范围。
我显然不是在这里解决一个新问题，所以问题是我的设计明显有什么问题以及正确的方向是什么样的。
也许我这边仍然存在误解，但我不认为每个应用程序用例实例都应该生成一次性LedgerAccounts，因为我们不会为HouseCash每个用例创建新的Deposit和Withdrawal。存款/取款也属于ApplicationTransaction类别，很少有状态转换（例如被支付处理器拒绝）。在真正的应用程序中，您有一个特殊的表来处理它，有付款方式和金额等。
否则这种做法将造成数十万的一次性LedgerAccounts。问题不是要求为宇宙建立通用系统的通用模型，而是方向是否正确的问题，不确定我们是否必须保留一次性账户，正如我已经说过的，我看到Account并且LedgerAccount作为生成 House 报告、维护客户帐户所需的东西，否则看起来就像在 AWS EC2 上为每个 CPU 核心定义帐户一样愚蠢。
参考数据模型
\n\n\n\n\n我更喜欢后一种具有规范化事务的模型。
\n
根据 SO 指南，每个答案仅限于问题。第一个答案中的数据模型满足问题，并假设了解账本。第二个问题假设不了解账本，因此第二个答案给出了账本的完整解释，并且需要更详细的数据模型。
\n\n无论如何，我们将使用第二个数据模型。
\n\n\n\n
问题\xe2\x80\xa2 方法
\n\n\n\n\n有许多状态长期运行的复杂操作。一笔大交易会影响许多分机。帐户（甚至许多分类帐），
\n
\n 您可以在其中回滚、添加新交易（又称为费用、罚款）或从所有涉及的分机重新分配资金。状态改变时的账户/账本交易。
绝对，绝对，不是。请忘记用 IT 或 CS 术语来思考。仅考虑会计术语（随后在实施时实施会计要求）。
\n\n- \n
每笔会计或商业交易都是单一的、即时的。
LedgerNo它的一侧涉及一个分类帐帐号，另一侧涉及另一个LedgerNo分类帐帐号或外部帐号。AccountNo\n没有等待，没有状态，没有进展。
\n不存在影响“许多外部帐户”（或许多其他分类帐帐户）的业务或会计交易。这种看法不是会计的看法。
\n\n- \n
- 如果你按照这些思路实施任何事情，你将不会拥有会计系统，你将拥有一个反会计系统（有或没有DEA），它无法记账，无法会计，也无法审计。 \n
\n您可以有一个影响多个帐户（Ledger-Ledger 或 Ledger-[External]Account）的过程。但该过程执行单个业务事务。其他答案中的示例是：
\n\n- \n
- \xc2\xa7 5/2 收取月费（伪代码）
\n想象BEGIN TRAN/COMMIT TRAN一下括号INSERT\n - \xc2\xa7 6.5。SQL 批量任务\xe2\x80\xa2 帐户月末\n它特别建议批量
执行SQL 事务。这意味着每 100 或 200 个业务事务执行一次“COMMIT TRAN/BEGIN TRAN”。通常会有重启控制等（如果不明白请询问。） \n
\n- \xc2\xa7 5/2 收取月费（伪代码）
\n\n\n我正在考虑带有操作类型鉴别器的通用操作表以及每个操作类型的许多特定表。
\n
（对操作表没有评论。）
\n\n关系或 IDEF1X 术语中的普通独占子类型集群。
\n\n\n\n\n...所以我们可以添加约束。我不确定它的位置在哪里，也许是应用程序代码。
\n
- \n
切勿在数据库以外的任何地方放置约束或任何限制数据逻辑（一致性）的内容。
\n数据库是单个恢复单元。它必须包含
\n\n- \n
- 所有约束（没有逻辑限制；关系数据库中的任何内容都可以根据 FOPC 谓词进行声明），以及 \n
- 所有交易，在存储过程中。 \n
\n所有表都
GRANTED SELECT只有权限，从不GRANTED INSERT, UPDATE, DELETE。 这意味着不能直接写入表。 \n事务（存储过程列表）是数据库 API。
GRANT EXEC许可要精心挑选Roles，因而要具体Users。 \n所有应用程序代码（在客户端或某些中间件层中）仅执行事务。仍然只有在允许的情况下
Users\n
否则，您就没有数据库，您将拥有不安全的数据混乱。请参阅开放架构标准。（这是供公众消费的简单定义。）
\n\n\n\n
问题 \xe2\x80\xa2 应用程序
\n\n\n\n\n操作的简单示例是一个投注，其中包含多个承诺，当您从每个参与者那里获取一些抵押品时。每个参与者甚至拥有不同的资产，House 可以使用其中的许多资产来满足某些要求。
\n
这些指示基于实施会计系统，对每笔会计交易进行复式记账，其中不会丢失金钱（或资产），并且可以轻松追踪任何差异......这使其可审计。
\n\n- \n
每个投注者都会有一个单独的外部
Account。 \n将有一个
AssetType表格定义不同类型的资产，即所谓的“抵押品”。考虑不同“货币”中的“货币”（因此 DEA 是可行的）。 \n将由
Account进行限定AssetType，给出AccountAsset表格。AccountAsset（而不是Account）将被交易。我们交易的是每笔资产AccountAsset，而不是金钱，也不是整体价值Account。 \n在账本方面，首先会有一个
Suspense或Pending账户。 \n接下来，您所说的“状态”是分类帐中的一个条目
\n\nSuspense。但是，甚至您的“状态”概念也必须加强以符合暂挂或待处理帐户的概念。因此我不能直接使用你的例子，我会给出我能确定的（请随意澄清或添加更多）。我暂时将其称为SuspenseState. 值为：- \n
开放投注（待定，未结束）
\n资金不足（投注结束，资产未收回）
\n\n- \n
- 还有进一步的细化，以确保防止这种情况发生。在
SuspenseStates正确确定之后，而不是之前，可以对此进行讨论。 \n
\n- 还有进一步的细化，以确保防止这种情况发生。在
\n接下来，在每个 下
SuspenseState，每个 都会有一个条目AssetType。这些都是LedgerAccounts针对所有外部交易的Accounts。[4][5] 不是事务性的，它们是聚合的LedgerIntermediates。 \n
您的数据模型
\n\n顺便说一句，图形很棒。感谢您用数据模型（图形）术语清楚地表达您的问题。
\n\n我已经按照我引用的要求回答了上面的问题，我对此有所了解。我看不出这与数据模型有何关系（要求：抵押品与数据模型：彩票）。我无法理解Operation正在做什么。您深入了解如何做您需要的事情，但我们还不了解我们需要什么。顺序是，首先定义什么，然后定义如何。
- \n
请用英语用技术术语解释一下（编辑你的问题），彩票和贸易（我理解这相当于在外部银行账户之间转账......但为什么要延迟，为什么不立即？）。
\n请解释每个“状态”的含义（一个句子标识所采取的行动以及每一方）：
\n\n- \n
AAA：新；完全的; 取消
\nBBB：待定；冲突; 解决
\nCCC：新；完全的;
回滚\n
\n为什么您的模型没有“抵押”类型 (
my AssetType) ？ \n警告。在每个文件上标记一个
\n\nID字段将严重削弱建模工作。为什么 ？因为您假设该文件是正确的，但事实并非如此。您正在修复“实体”，而“实体”尚未建模。建模的目的是对数据进行建模，仅对数据进行建模，而不仅仅是数据（场ID不是数据，而是附加物）……从而使“实体”被暴露、提炼、确定。因此，为了进行一些真正的数据建模，请删除这些
\n\nID字段。这意味着，您必须为每个更正的文件选择一个逻辑标识符，该操作会将其提升为表的状态。关系模型要求密钥“由数据组成”。如果
ID保留字段，则会有进一步的警告，我不会详细说明，因为如果将它们删除，警告也会消失。（这些都是常见问题。如果有兴趣，您可以阅读我的其他一些答案，其中我详细介绍了每个问题并给出了解决方案。） \n