For good or for ill, as someone pointed out to me not too long ago, we
don't all have the luxury of working with well denormalized systems. It
turns out that the many attempts to denormalize the table that I think
of first have all failed miserably because their performance impacts
were too great.

User A is a live person. Users B and C are automated processes
triggered by real-world events. The cranes table is a legacy table that
maybe should be denormalized, but past attempts to denormalize it have
failed miserably so it remains.

User A is a construction manager assigning an operator to a crane. It
is Evil, but the current operator is stored on the crane status table.

"User" B updates the GPS location of the crane.

"User" C throws up a warning flag because the crane has reached an HOS
benchmark and will require maintenance in the near future.

On Fri, 2005-10-07 at 11:18 +0400, Dmitry Sibiryakov wrote:
> On 7 Oct 2005 at 8:09, Kjell Rilbe wrote:
>
> >Dmitry Sibiryakov wrote:
> >
> >> Actually, the problem is a matter of authority. Why all A, B and C
> >> are allowed to edit the same record? Who has "more right"
> >> information?
> >
> >A is updating the order record because she got a notification that the
> >goods has been delivered while B is updating it because he's just
> >mailed the invoice, and C is updating it because the customer just
> >called to say that she will be returning one of the items because it
> >was damaged?
>
> It smells like denormalized DB structure.
> Can't say about delivery confirmation, but history of sent invoices
> and accepted reclamations I'd put into separate tables...
>