Re: Implementing "thick"/"fat" databases

> 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