[Nottingham] SQLite and 'locking'

[Duncan John Fyfe]

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

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

It is. 

> 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.
> 

And I have the scars from walking the pure-OO DB (called O2) road.  I
don't want to go that way again (and no it wasn't by choice the first
time round).
I see databases much in the same way I see security.  You can devise the
perfect system but if it makes life difficult users will work around you
and not with you.  Until somebody comes up with the perfect usable
system (and isn't vapourware) then we are all just trying to get the job
done the best way we can with what we have.  

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

I'm not sure what you mean here.  Certainly SQLite doesn't enforce
foreign key constraints which makes the kind of error I think you are
alluding to possible while suitable constraints in for example
postgresql would make it impossible.

Have fun,
Duncan