[Nottingham] SQLite and 'locking'

[Martin Garton]

On Tue, 2007-02-27 at 09:06 +0000, Duncan John Fyfe wrote:

> But surely Martin's solution is wrong because it depends on a meaning
> being ascribed to NULL.  NULL can arise from conditions other than those
> anticipated and when it does you will be unable to distinguish 'not
> booked' from 'another condition you did not anticipate'.

A meaning being ascribed to null may be wrong in relational theory[1],
and may be unpleasant to some, but certainly works perfectly well in
many real situations.  In fact solutions like mine often work better in
practise. One reason is that because by always avoiding nulls at all
costs can actually make things harder for developers to understand and
so bugs spring up for different reasons.

Also, taking things to the extreme (6th normal form for example) tends
to destroy performance in many use cases.  Perhaps the performance issue
from such normalisation should be something that the RDBMS vendors
should work on, but until they do, and until developers in general are
comfortable and competent enough to work with such database designs, I
will be continuing to suggest solutions that ascribe meanings to null.

-- 
Martin.

[1] Or maybe it's not.  I'm not too familiar with relational theory.  It
has always struck me as more useful to scientists than to engineers and
when it comes to databases I have my engineer hat on.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://mailman.lug.org.uk/pipermail/nottingham/attachments/20070227/5bb26abb/attachment.bin