> In LedgerSMB, we take this a step further by making the procedures > into discoverable interfaces, so the application logic itself is a > sort of thin glue between a UI layer and the database procedure layer. > One thing I would suggest is to try to keep API calls as atomic as > possible. You want to enforce consistency and so you need to have all > relevant inputs passed to the function. See below for a suggested > change to your API.
Would you say LedgerSMB follows the thick/fat database principle? If so, I shall have to spend some time with your source code. I'd be very curious to see how you handle this. > > BEGIN; > > SELECT create_transaction(1, current_date, 'Transaction 1'); > > SELECT create_line_item(1, 1, 50); > > SELECT create_line_item(1, 1, -50); > > END; > > Now, if you are doing double-entry bookkeeping this doesn't provide > enough consistency, IMO. You can't check inside the function to > ensure that the transaction is balanced. Yes, but I'd implement the constraint "all transactions must balance" as a trigger that fires when the transaction is complete. This would enforce data integrity regardless of whether or not the database API is used, which I think is also important. Karl Nack Futurity, Inc 5121 N Ravenswood Ave Chicago, IL 60640 773-506-2007 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
