Re: "Transactions are bad, real bad" - discuss

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<b8p42r$1ltu$1_at_gazette.almaden.ibm.com>...

> I want to offer you some alternate solutions.
>
> A) Invoice lines are persistent
>
> Each invoice line is stored in the database in a set of tables set aside for
> 'invoices in progress'. These tables have the relevant constraints on them and
> as each line is inserted (and committed) into these tables, the constraints
> are checked. Once an invoice is complete - defined by say a view over the
> 'invoices in progress' it can be moved into the 'main' database tables.

I like it very much!

I would implement it adding a "Completed" boolean attribute to the invoice header.

I could declare a "CompletedInvoices" view, and then I would not need to move anything.

It is very good for me because the users will see the article stock variations instantly. It is important when you work with articles with serial numbers.

> Frankly this is the best design. It avoids issues such as not defining the
> constraint
> 'Every invoice must have at least one line'

It should be:

'Every completed invoice must have at least one line'

> B) Invoice lines are not persistent
>
> As above, but the tables set aside for 'invoices in progress' are local,
> in-memory tables on the client. Again, the constraints on these will be
> similar, but not identical to those on 'completed invoices'.

I have considered it, but I would need a local DBMS on the client, and several constraint violations would not be detected until the invoice completion.

> The problem we have is: how do we get to test the DBMS constraints against our
> 'invoice in progress' without actually doing an update? Now the constraints
> are available in the catalog, all we need do is pull them out and test them
> against our proposed update.

But the constraint could be violated only after the test.

IMHO it looks a lot like a distributed database update with defered synchronization, and frankly I don't like it.

Where would we 'store' the proposed updates?

In a relational table?

Proposed updates looks very similar to uncommited updates.

Thanks a lot for your suggestions. I think I will use the A)

Regards
  Alfredo Received on Sat May 03 2003 - 20:34:14 CEST