Mirroring all of the information that bitcoin keeps about transactions inside your bitcoin-oriented web app is probably not the right way to go.
Well, then the bitcoin client might have to mirror all the functionality that's available when doing SQL queries against a full fledged RDBMS.It violates the zero/one/infinity principle, and you're likely to have subtle bugs if (when?) the two copies get out of sync.
I don't really see how, if you're talking about scalability issues that would get solved by nice bitcoin callbacks.See: http://www.bitcoin.org/wiki/doku.php?id=accounts for "best practices". If you're willing to share what kind of thing your web app is doing, I'd be happy to brainstorm other approches, too...
Okay, so here's how bitcoin central handles it.It polls the client at regular intervals and does exactly what lucky said, it INSERTs unknown transactions, and updates the confirmations of the known ones (and no, the tx_id is not defined as unique
)It polls the client for each account, not for a global listtransactions (which doesn't really seem to work anyway AFAIK).
Yes, this approach is sub-optimal, but IMO it's the only one that allows enough flexibility in the ways you want to deal with the data.
I'm completely conscious of the limitations and possible security flaws of this approach, and that's why the bitcoin central code *also* takes advantage of the accounts functionality, providing a second security layer.
That, IMHO is the best possible approach for a web app.
)