PHP Mysql-使用分组依据的交易

Question

i am trying to create a banking system in PHP and mysql. Right now i have a transactions table that has columns like:

id (bigint) | account_id (int) | amount (decimal(10,2) SIGNED) | type (credit/debit) | created_on (timestamp)

so to get a total account balance the query would look like:

select sum(amount) from table where account_id = ? group by account_id order by created_on asc

we need to have a transactions table that breaks down every transaction within the system. Im just not sure this should be the single source of truth, especially considering the need for transactions with depositing/withdrawing/sending money

Does the single transaction table scale? what happens with a withdraw, where we need to get the balance, check against the withdrawal amount and then either insert into the transaction table or fail?

Would it be easier just to have two tables, one for transactions, and another for account_balances, that way for withdrawals we just need to do:

UPDATE account SET balance = balance - ? WHERE id = ? AND balance >= ?

Thanks Brian

Answer 1

Im just not sure this should be the single source of truth,

There can be only one source of truth about any given fact, by definition.

Attempting to create a second source of truth means you have no source of truth, because it relegates both to mere sources of potentially inconsistent opinions.

Keeping a separate table with balances is delicate territory. It's easy to make naïve assumptions that overlook this.

In spite of this, it could make sense, for example, to have a table with static balances so that you have a lightweight option for fetching the customer's balance for display at the top of each page... but this table has to be treated like the untrustworthy villain that it is (or can become).

Tables like this are particularly prone to novice mistakes that lead to race conditions and anomalies, such as reading the balance into a variable, programmatically adjusting its value, and writing the new value back to the database. That's simply not how you do it. Yet, I've seen it done that way so many times (particularly by people who still fail to understand that there is no such thing as a good ORM, because ORMs are an intrinsically flawed concept). Such a table should be maintained by triggers, not by application code, and updates should be atomic.

You did show an atomic update in your example...

UPDATE account SET balance = balance - ? WHERE id = ? AND balance >= ?

...although you need to use caution, here, because this will successfully update 0 rows if balance >= ? is not true... and, much worse, a bug in your code where the first placeholder value is null, SET balance = balance - NULL will set the balance to NULL, since a null operand (correctly) causes most operations to evaluate to null.

If you want this table as an optimization, then safe design would always ensure consistency by auditing the balance with a calculation from the transactions before doing anything important (like a withdrawal or transfer), and blatantly refuse to proceed if a discrepancy is found, explaining to the user that the site is "having problems" and creating an internal support incident for you... because this means you have a bug that is allowing the values in the balance table to diverge from the transaction table, which is a sign of Very Bad Things™.

Much of this of course is mediated by using database transactions correctly, understanding isolation levels and using locking reads in critical sections. If the balance table is only modified by a BEFORE INSERT trigger on the transaction table, and not by your code, then there few opportunities for the balance to drift.

Sanity check are still critical, and in spite of all the hand wringing and arm waving you'll get from people who insist that triggers have excessive performance penalties and should be avoided... they have absolutely no idea what they are talking about. Yes, technically speaking, the mass of the fuel in your car's fuel tank has a negative impact on your fuel economy, but it's a critical part of the operation. You don't give it any thought. You don't drive around with a mostly-empty tank. The cost of firing triggers is negligible, particularly in light of the way they help a database look after itself. Don't give the cost of triggers a second thought.

But the scalability concern for a table like this is largely taken care of by proper indexes. An index in the transaction table on (account_id, created_on), for example, means the database has a way of instantly locating all of the transactions for one specific account, already sorted by the order in which they occurred, without scanning the table. You should find that even among hundreds of millions of rows, finding the transactions for a given account is speedy, with a proper index.

SELECT sum(amount) implies that the transaction amounts are signed, which means the type column is somewhat superfluous, though you might want to keep it and trap it with a trigger requiring credits to be > 0 and debits to be < 0. Sanity checks inside the database, regardless of how seemingly-obvious/unnecessary are, are rarely a bad idea when money is involved.

You should probably also have BEFORE DELETE and BEFORE UPDATE triggers that deny any changes to the transaction table. Transactions are historical facts that do not change. An incorrect transaction is properly undone by creating a second, offsetting transaction.

A simple example of preventing all deletes on a given table in MySQL Server 5.5 and later looks like thjs:

mysql> CREATE TRIGGER transaction_bd
       BEFORE DELETE ON transaction
       FOR EACH ROW
       SIGNAL SQLSTATE '45000'
       SET MESSAGE_TEXT = 'the transaction table does not support DELETE.';

(The usual DELIMITER declarations aren't needed for a trigger with a non-complex body.)

Answer 2

I think it's better to have two separate tables for incoming(deposits) and outgoing(withdrawals). All positive go to incoming and negative to outgoing, then you assign whatever type you want. However, its an architecture problem, and without knowing your entire platform requirements it's very hard to tell.