From: David Masover <ninja@...>
Date: 2010-12-07T07:53:13+09:00
Subject: Re: Q: what database would you suggest?

On Monday, December 06, 2010 01:48:18 pm Petite Abeille wrote:
> On Dec 6, 2010, at 12:48 AM, David Masover wrote:
> > least bound to SQL at all (let alone SQLite) if you decide to
> > change in the future.
> 
> "Prepare Now For Possible Future Head Transplant"
> http://database-programmer.blogspot.com/2010/11/prepare-now-for-possible-fu
> ture-head.html

I don't have time to do a point-by-point rebuttal, so for now:

"So what about that weird title involving head transplants? Obviously a head 
transplant is impossible, making it also very unlikely, besides being silly 
and non-sensical. It came to mind as a kind of aggregrate of all of the 
bizarre and unrealistic ideas about abstracting data designs that I have heard 
over the years."

Huh?

Having something that's at least abstract enough to deal with multiple 
databases is something I have actually used. That is, as a matter of 
convenience, I've actually developed applications using SQLite and deployed 
them to MySQL.

And it's not always just SQL.

I've also migrated models from one application to another -- that is, I took a 
model which used to be internal to both applications A and B, along with code 
that made assumptions about that model, and made it live in application A, 
with application B accessing it via REST.

So, if you're keeping track, that's the same model, used for both REST and 
SQL. Far from impossible, silly, or unlikely, the fact that we were using 
abstractions which allowed for this possibility increased the likelihood that 
we'd actually do it.

It's also possible the article misses one of the main points of an ORM. Even 
if I were writing a SQL-only application, I'd have to be insane to use raw SQL 
to deal with it when I can have 90% of the work done for me by the ORM -- that 
is, 90% of what any application does is trivial CRUD, and there's no reason I 
should have to rewrite that every time.

> > One thing to be aware of with SQLite is that it essentially locks the
> > entire database for any operations.
> 
> Hmmm?!? Not quiet.
> 
> http://www.sqlite.org/lockingv3.html
> http://www.sqlite.org/wal.html

Yeah, reading the 3.0 summary confirms all writes are an exclusive lock over 
the entire database. My bad, that is different than locking for _all_ writes, 
but it's still something you want to be aware of during the design phase, 
especially if someone follows your advice and doesn't abstract sufficiently 
that they can easily migrate away later.