database design for accounting systems
Generally accounting systems have a large General Ledger table. Each row on the table is a transaction, functioning more like a star schema rather than a traditional 3NF relational database. In this way they are normally a hybrid of both star/snowflake and relational combining the best of both worlds where possible. They are generally not strict 3NF databases, with some duplication in the GL table in terms of project codes or business unit codes. For instance they will often look like this:



Records are not usually updated in an accounting systems. What happens instead is additional transaction rows are added which reflect the amendment in the previous entered value. For instance, if you wanted to change the Transaction Amount for BU Code A100 above to 50 instead of its current value 100, you would add a line:



If you wanted to delete that line then you would add a row similar to the above, but with -100 in the Transaction Amount (and then mark this as a reversal in the transaction types). 

Generally computers are pretty fast at the adding part of this, there are various partitioning tricks you can use to improve performance. All vendors are very fixated on improving the performance, so you usually don't have an issue. With modern DBs indexing, they usually update quite fast though there are often lags. 

For real performance the accounting system data is usually put into an OLAP cube, where further speed efficiencies can be obtained and more analytic type queries can be answered.