会计数据库 - 存储交易
您制作了一个游戏网站，用户可以在其中购买游戏积分，并将资金存入/记入用户的虚拟帐户以玩一些游戏等。
1
如果您有一名会计师来记录交易，则会将其记录下来像这样（可能有点复杂，但你明白了）
TRANSACTION
PK_ID1 Cash - $10 (System)
PK_ID2 Deposit $10 (System)
TRANSACTION
PK_ID3 Bank Account - $10 (John)
PK_ID4 Deposit $10 (John)
2
作为开发人员，你真的需要浪费 2 条额外的记录吗？为什么不这样记录呢……（然后你可以在同一存款记录下的其他列中存储资金来源、状态等信息）
TRANSACTION
PK_ID1 Cash - $10 (system)
PK_ID2 Deposit $10 (John)
选项#1相对于选项#2和副签证有什么真正的优势吗？
编辑：修改问题，删除 CR、DR 并替换为符号。
You make a gaming website where the user can buy gaming credits and the funds are deposited/credited into the user's virtual account to play some game etc...etc..
1
If you got an accountant to record the transaction, it would be recorded like this (maybe a bit more complex but you get the point)
TRANSACTION
PK_ID1 Cash - $10 (System)
PK_ID2 Deposit $10 (System)
TRANSACTION
PK_ID3 Bank Account - $10 (John)
PK_ID4 Deposit $10 (John)
2
As a developer, do you really need to waste 2 extra records? why not just record it like this…(then you might store information where the funds came from, status in other columns under the same deposit record)
TRANSACTION
PK_ID1 Cash - $10 (system)
PK_ID2 Deposit $10 (John)
Is there any real advantage of option #1 over option #2 and vice visa?
EDIT: modified question, removed CR, DR and replaced with a sign.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
（回答你的问题，但也回应 paxdiablo 的回答中提出的一些观点。）
这与会计师查看你的数据库无关。通过复式录入，错误很容易追踪；这是会计和国税局的要求，所以实际上，您别无选择，任何处理公共资金的系统都需要复式记账。
（请不要试图告诉我什么是“复式记账”；我已经根据审计要求为银行编写了复式记账系统。）复式记账是一种基于一组帐户的会计方法。每一笔金融交易都是日记账分录；如果所有交易从头开始重新应用，所有帐户的余额将与今天完全相同。
双重记账是指每笔交易都有一个“To”和一个“From”账户；金钱永远不会离开系统或进入系统。每个贷项都附有一个借项。
因此（1）不是（2）的“复录”版本，它们不能轻易进行比较。约翰交易的复式记账版本是（一笔金融交易），用逻辑会计术语来说：
发件人：
JohnAccount致：SystemAccount金额：10.00（美元）这很可能是表中的两行，一行是贷方，另一行是借方，这两个插入包含在 SQL 事务中。
这就是会计系统，它是内部的，与金钱打交道。我们已经完成了。
但是您还将会计系统与购买/销售系统结合起来（没有明确声明）。当然，对于你从约翰那里拿走的十块钱，你需要给他他购买的任何东西，并记录下来。约翰购买了价值十美元的游戏积分，如果您正在跟踪它，那么是的，您还需要：
SystemGamingAccount致：JohnGamingAccount金额：100（积分）或者，以美元表示：
发件人：
SystemGamingAccount至：JohnGamingAccount金额：10.00（美元）这也很可能是表中的两行，一行是贷方，另一行是借方，四个插入包含在一个 SQL 事务中。
需要明确的是，如果您销售的是小部件而不是游戏积分，则第二笔（小部件跟踪）交易将是：
发件人：
仓库发件人：PublicSale金额：1（小部件）并且由于您跟踪的是仓库中的单位，而不是 John Q Public 口袋里有多少个小部件，即两次插入加一次更新 (
UPDATE Part SET QtInStock = QtyInStock - 1 WHERE PartCode = “Widget”），全部封装在 SQL 事务中。每个用户都有一个帐户，对吧。无论是虚拟的、深奥的还是物理的，它都是一个法律实体，可以根据它进行交易。因此，我们不要因为它是虚拟的而假装它不存在。对于游戏，一美元帐户加一个游戏（信用）帐户。
信用卡/借记卡
我会将 CR/DB 放回；不是 CHAR(2)，而是布尔值。当表很大时，它会帮助你，
快得多
比注意使用“>=”你必须确保每个代码段都以相同的方式编码，而不是“>”要 。有时。 Boolean 或 char 不存在这个问题。
(Answering your question, but also responding some points raised in paxdiablo's answer.)
It is nothing to do with the accountant looking inside your database. With Double entry, errors are easy to trace; it is an Accounting and IRS requirement, so really, you do not have a choice, you need double entry for any system that deals with public funds.
(Please do not try to tell me what "double entry" is; I have written double entry systems for banks, to Audit requirements.) Double entry is an accounting method, based on a set of accounts. Every financial transaction is Journal Entry; if all the transactions were re-applied from the beginning, all the accounts would at their exact same balance as they are today.
Double Entry means every transaction has a "To" and a "From" account; money never leaves the system or enters the system. Every Credit has a Debit attached to it.
Therefore (1) is not the "double entry" version of (2), they cannot be readily compared. The double entry version of John's transaction is (one financial transaction), in logical accounting terms:
From:
JohnAccountTo:SystemAccountAmount:10.00(dollars)That may well be two rows in a table, one a credit and the other a debit, the two inserts wrapped in an SQL Transaction.
That is it for the Accounting system, which is internal, and deals with money. We are done.
But you are additionally marrying the accounting system to a purchase/sale system (without having explicitly declared it). Of course for the ten bucks you took from John, you need to give him whatever he purchased for it, and record that. John bought ten bucks worth of gaming credits, if you are tracking that, then yes, you also need:
SystemGamingAccountTo:JohnGamingAccountAmount:100(credits)or,expressed in dollars:
From:
SystemGamingAccountTo:JohnGamingAccountAmount:10.00(dollars)That, too, may well be two rows in a table, one a credit and the other a debit, the four inserts wrapped in an SQL Transaction.
To be clear, if you were selling widgets instead of gaming credits, the second (widget tracking) transaction would be:
From:
WarehouseTo:PublicSaleAmount:1(widgets)and since you are tracking Units in the warehouse but not how many widgets John Q Public has in his pocket, that is two inserts plus one update (
UPDATE Part SET QtInStock = QtyInStock - 1 WHERE PartCode = "Widget"), all wrapped in a SQL transaction.And there IS an Account for each user, right. Virtual, esoteric or physical, it is a Legal Entity, against which transactions are made. So let's not pretend it does not exist because it is virtual. For gaming, one dollar Account plus one gaming (credit) Account.
Credit/Debit
I would put the CR/DB back in; not CHAR (2), but boolean. It will help you later when the table is large,
is much faster than
Note that with ">=" you have to ensure that every code segment is coded the same way, not ">" sometimes. Boolean or char does not have that problem.
就数据而言（这就是您所要求的），没有。您应该将其存储为有符号值。复式记账不是暴民所做的事情，因此它可以向国税局隐藏真实利润:-)
这意味着交易必须平衡（价值永远不会被创造或破坏，只是被转化）。如果您只是将交易（和账簿）存储在带有标志的一列中，那么平衡交易（和账簿）就会容易得多。
在视觉呈现方面，一些会计师可能喜欢将它们放在单独的列中，但绝大多数人会生成带有“否定”的报告，只是以不同的方式表示（例如用括号将它们括起来）。
很可能（像许多其他会计事物一样），双栏是从许多个月前延续下来的。将两列相加然后从正总数中减去负总数以获得当前位置会更容易（而不是以混合方式进行加法和减法）。但这是我的假设。
另请参阅此处。
需要明确的是，如果价值本身实际上是通过银行帐户传递的，会计师只会使用银行帐户执行两步流程。如果这只是从一个用户到另一个用户的价值转移，那么银行账户就不会参与其中。
因此，用户到用户的价值转移类似于（将交易部分从整个交易中分离出来，以允许复杂的多账户移动）(1)：
价值传递的地方通过您的银行帐户可能是：
对于外行来说，请记住，当资产/负债对您有利时却具有负值，这是很奇怪的:-)
(1) 为了避免混淆（请参阅评论），我应该强调，分成几部分是为了允许交易轻松触及多个帐户代码（各种资产、费用等）。事务本身仍然是单个原子操作。
In terms of the data (which is what you're asking), no. You should store it as a signed value. Double-entry bookkeeping is not something the mob does so it can hide the real profits from the IRS :-)
It means transaction have to be balanced (value is never created or destroyed, just transformed). And it'll be a lot easier to balance transactions (and the books) if you just store them in one column with a sign.
In terms of visual presentation, some accountant may like them in separate columns but the vast majority will generate reports with the "negatives" simply indicated differently (such as surrounding them with parentheses).
It may well be that (like many other accounting things), the dual columns are carried forward from many moons ago. It would be easier to add up two columns then subtract the negative total from the positive total to get the current position (as opposed to adding and subtracting in a intermixed fashion). But that's supposition on my part.
See also here.
And just to be clear, an accountant would only do the two-step process using a bank account if the value itself actually passed through that bank account. If it's simply a transfer of value from one user to another, the bank account doesn't get involved.
Hence a transfer of value, user-to-user would be something like (splitting transaction parts from the transaction as a whole, to allow complex multi-account movements)(1):
One where the value passed through your bank account could be:
That's keeping in mind the, to the laymen, weirdness of assets/liabilities having negative values when they're good for you :-)
(1) To avoid confusion (see comments), I should stress that the separation into parts is for the allowance for a transaction to easily hit a multitude of account codes (various assets, expenses, and so on). The transaction itself is still a single atomic operation.