问题：在以下情况下，我是否应该将所有金额存储为正十进制金额，然后将该金额标记为“借方”或“贷方”，而不是将借方存储为负数，贷方存储为正数？
在我的数据库设计中，我将“借方”存储为负数，将贷方存储为正数。
现在在报告中有时结果会出错，因为如果你这样做
TotalAmount = Amount-Fee，如果取款金额为$100，手续费为$1。
你最终会得到 -$100-$1 = -$101，这是不正确的结果！
【问题讨论】：
标签： sql-server database sql-server-2008 database-design accounting
正如您所发现的，对所有内容使用一列，然后对借方或贷方使用负数是行不通的。会计值不是标量——它们是包含枚举（借方或贷方）和定点十进制数（可以是正数或负数）的向量。
任何会计交易必须包含相同数量的借方和贷方。如果没有，则不是有效的交易。
同样，账户余额也是同一种向量。在任何时刻，会计系统中所有账户的总借方和总贷方必须彼此相等，否则就会出现问题。
另一种看待这个问题的方法是将会计价值视为一个复数，其中借方是实数，贷方是虚数。这意味着 4 借方 + 3 贷方 = 4 + 3i。这很明显，您不能通过将虚项折叠为负实项来进一步简化它——它不是同一个数轴。这与声称 4 + 3i = 4 - 3 相同。数学无效。
如果数据库可以原生存储复数，那么复数实际上将是存储会计数据的好方法，可能会消除程序员通常对会计的许多困惑，并会带来各种有趣的东西特性。例如，平衡的交易总是有 45 度的相位角，平衡的账户集也是如此。但是大多数数据库需要您在存储之前将复数分解为其实部和虚部，并将这些项存储在不同的列中——在会计领域，这两列的名称分别是“借方”和“贷方”。
P.S.：我知道有些人确实对贷方使用负数，对借方使用正数，但这样做需要非常小心，而且很脆弱。每次接触任何账户时，您都必须跟踪它的正常余额——例如，由于资产账户有借方正常余额，那么您可以使用正数来增加它。但是负债账户的正常余额为负数，因此该账户价值的增加是一个负数。你不能在任何时候把这两个值加在一起——它们不是一回事。借记是您拥有的东西，而贷记是您欠的东西。将两者放在数据库表的同一列中很糟糕。
【讨论】：
由于会计完全基于日记帐分录，因此您的数据模型可能最好以此为基础。这意味着您的表中有两列，一列用于借方，一列用于贷方。然后由应用程序决定什么应该被认为是“正”值，什么应该被认为是“负”。 （问题总是出现 - 从谁的角度来看是积极的？当您在银行账户之间转账时，它对一个账户来说是“消极的”，而对另一个账户来说是“积极的”。）
我已经有一段时间没有做这种事情了，但我似乎记得借方和贷方列可能同时包含正值和负值。会计师对数字的思考方式与我们程序员不同，因此在为他们编写软件时，如果您尝试遵循他们的惯例，它可以简化事情。
【讨论】：
我使用 Sage Timberline 会计系统，它将借方保存为正数，贷方保存为负数。在包括试算表在内的所有报告中，您都会进行借方 + 贷方。然后，您为借方冲销做负借方，为贷方冲销做正贷方。工作正常
【讨论】：
好的，我参加聚会有点晚了，但这里有一些有趣的答案，我想我应该补充一下。
回答这个问题：您应该将值存储为正数并标记为借方还是贷方？
简短的回答：您不需要添加标志，因为当您以正确的签名形式保存号码时，任何系统都会自动应用标志“借方”或“贷方”。这是“-”号。您应该将值存储在借方或贷方两列之一中吗？当然不 ！为什么要为系统中的每笔交易保存一个空白字段？具有正确符号值的单列更易于管理。
问题标题的较长答案：会计和数据库设计，存储借方和贷方金额。
只要您了解复式记账法，它就非常简单且可靠。当您将日记帐过帐到名义分类帐时，您为用户提供了日记帐中每一行的借方字段和贷方字段。在您的应用程序中，您只允许其中一个字段具有值（每行），并且它必须是正的、无符号的值。当你写交易时，如果你有借记，你就按原样写。如果信用字段中有值，则将其反转并将其写为负数。数据库在每行（记录）的单个列中只能看到一个带符号的值。任何会计师都会告诉您日记帐分录必须平衡，因此日记帐交易行的数据库记录加起来为零。应用程序代码必须确保日志必须是平衡的。
现在考虑用户添加到系统的购买发票。假设我们有 Widget Company 的这张（不太可能的）发票：
钢筋 500 英镑
一盒信封 100 英镑
10000 英镑的车床
2120 英镑购置税
12720 英镑的发票总额
应用程序将单个记录写入文档表。它具有到事务表的一对多链接。对于三行发票，应用程序写入 5 个交易行。
500 英镑与销售成本相关联，这是一个损益总帐帐户。借方余额 = 损益时的费用
£100 关联到 Stationery，这是一个损益总账账户。借方余额 = 损益时的费用
£10000 链接到机械，资产负债表总分类帐帐户。借方余额 = 在银行时的资产。
2120 英镑与可退还进项税相关联，这是一个 bs gl 帐户。借方余额=资产，税务员欠我们钱
-£12720 链接到 Creditors Control，一个 bs gl 帐户。贷方余额=负债，这是我们欠供应商的
写入交易表的 5 条记录的总价值 0.00 英镑。
现在考虑用户添加的销售发票：
高级小部件 250 英镑
标准小部件 250 英镑
100 英镑的销售税
600 英镑的发票总额
再次将一条记录写入文档表。对于两行发票，写入 4 个交易行。因为这是一张销售发票，所以应用程序必须在后台反转值。销售发票行是簿记信用，但用户不希望将它们添加为负值。
250 英镑 - 链接到 Premium Widget Sales，一个盈亏账户。贷方余额=损益时的收入/利润
250 英镑 - 与 Standard Widget 销售相关，这是一个损益表帐户。贷方余额=损益时的收入/利润
£100- 与应付销项税挂钩，一个 bs gl 帐户。信用余额 = 在 BS 中的负债。我们欠纳税人这笔钱。
£600 链接到 Debtors Control，一个 bs gl 帐户。借方余额=资产，这是客户欠我们的。
写入交易表的 4 条记录的总价值 0.00 英镑。
如果您想为退回的商品提供信用，可以在销售发票中添加负数行。在编写交易之前，它们只是与所有其他行相反。更常见的是，您会签发一张贷方通知单，其中的行记为销售收入的借方，从而降低损益表中的销售价值。
如果系统进行库存控制，数量将写入交易行，并将它们链接到产品表。
银行分录经常把非簿记员赶出去。他们说，我们把钱存入银行，所以我们记入了账户。将银行视为企业外部的人。当您交出钱以妥善保管时，她/他将成为债务人，并且必须按要求归还您的钱。因此，银行的收入记录为借方，而支付的款项记录为贷方。当我们收到客户的付款时，我们会编写两条交易行：
£600 链接到银行账户，一个 bs gl 账户。借方余额 = 增加资产的价值，我们有更多的钱。
600 英镑 - 链接到 Debtors Control，一个 bs gl 帐户。贷方余额 = 降低资产价值，欠我们的钱更少。
写入事务表的 2 条记录的总价值 0.00 英镑。
如果您按照此操作，您会看到在开具销售发票时，Debtors Control 已写入 600 英镑，在收到付款时已写入 600 英镑。净余额 = 0.00 英镑，这是我们客户现在所欠的。
因此，通过正确的设计、关系和索引，所有报告都是通过文档和交易的组合完成的。
就是这样。每次对事务表求和时，它都应始终返回零。无需维护两列。应用程序需要做两件事，需要对其进行编码，以便将正确的签名应用于各种交易类型，并且需要根据交易是 >0 还是
建立一个在一个交易中记录双重输入的双方的系统很有吸引力。如果单笔交易失败，它不会使账户失衡。您仍然只有一列的值，已签名。您将为每笔交易记录两个 gl 外键，一个用于记录您记录的值，可以是表示借方或贷方的正值或负值，另一个 gl 外键用于记录您发布的帐户反对（'双重输入'）值。您可能还需要为两个税控帐户记录 gl fk，一个用于销项税控制帐户，一个用于进项税控制帐户。因此，您最终可能会将您的交易行链接到四个 gl 帐户，而不仅仅是一个（加上适用于这两种方法的客户、供应商和产品表的链接）。控制账户将有大量与之相关的交易。一张 10 行的发票将有 10 个交易链接，而不是每个文档只有一个。您必须单独计算每个发票行的税项，而不是作为文档的总计（无论如何您都可以这样做）。最后，您必须对日记帐分录文档进行特殊安排，其中可能包括 10 行作为借方，所有借方作为贷方抵消，因此单交易方法在这里不起作用。
【讨论】：
您可以使用sql server 中的ABS 函数来获取绝对值。这将允许您将负数视为正数。
例如：
select ABS(-100)
返回100，而不是-100。
【讨论】：
这是来自一本名为“数据模型资源书”的好书的事务详细信息架构。此架构无需使用两列即可满足所有记录要求。
PK TransactionID - int
PK TransactionDetailSequenceID - smallint
Amount decimal
CreditDebitFlag char(1)
简单而有效，并且不像这里的其他答案所建议的那样使用无关的列。一列可存储所有数值数据，同时仍让您能够正确跟踪资产和负债账户。
【讨论】：
虽然已经有一个公认的答案，这也是问题的重点，但我也想分享我的意见，因为它可以帮助其他人在设计数据库时做出特别决定！
总体而言，两者都有各自的优缺点，并且可以通过使用abs() 来轻松结束问题，就像接受的答案一样！但是，当您跨团队交谈时，问题就来了，不同的人可能有不同的想法，并且相信我保存 (-ve) 值实际上会引起更多的混乱，特别是当他们直接从数据库中读取值时！
在大多数情况下，我不反对在借记时将 -ve 值保存在数据库中，但保存 +ve 实际上会减少混淆，即使作为数据库程序员也是如此，因为我们总是有一列告诉（是借记还是贷记）和想要编写代码的人可以轻松地在应用级别进行转换。
只有在数据库级别使用 sum(value) 时例外，但实际上这是最少使用的场景，因为在会计中我们主要显示运行余额，而在应用级别我们可以使用 (+) 或 (-ve)。
我想提出的一点是，数据库可以用于公司视角或客户视角，现在公司拥有从两个角度思考的数据分析师，一旦我们只保存 +ve 数字，它就会变得更容易记住，因为我们已经有了一个标志知道什么是什么值！
【讨论】：