[Nottingham] SQLite and 'locking'

[Martin Garton]

On Wed, 2007-02-28 at 10:17 +0000, Duncan John Fyfe wrote:

> Much code has and is
> being written (eg. http://www.catalystframework.org/) which abstracts
> SQL queries and moves the 'leg work' of the database into the
> application leaving the database to store serialised objects or
> something similar.  Most of this is happening because it means the
> application will work with any underlying database which implements a
> certain subset of SQL92 rather than having to implement compound data
> types for every conceivable database (different API, different language
> bindings , ...).    This approach does carry a whole host of issues but
> at least they and the application are portable between databases :) and
> I can understand why this is attractive to application developers.

What you describe is interesting and sounds a lot like various ORM tools
I have used.

It's can be contraversial but I see it simply as a different way of
using the database.  When programming in OO languages, the relational
model doesn't always fit nicely.  Either object based design or the
relational model has to win.  I prefer to think in objects so the
database is designed to fit in around that (or more often the database
isn't designed at all but is automatically derived from the class
designs).  Usually this ends up with the database being reasonably well
normalised but you certainly get columns that are allowed to be null.
If there is a column that really can't be null then fine, you can add
NOT NULL to the column, but the code in the class really should catch
that anyway.  That's part of its job after all.

> > Do you mean for columns where NULL has no meaning that you have ascribed
> > to it?  I don't yet see what alternative prevents coding errors.
> 
> It doesn't prevent them but it helps catch (insert a NULL in NOT NULL
> column) them at run time.  If NULL is (unnecessarily) permissible then
> your database cannot help catch implicit undef <=> NULLs caused by
> coding errors.  

Doesn't your multiple table approach just trade a potential null field
error with a potential missing-record-on-one-of-the-tables error?

-- 
Martin.

-------------- 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/20070228/a681bbcb/attachment.bin