From: Jeff Davis <ruby@...>
Date: 2008-05-26T02:02:39+09:00
Subject: Re: Yup, it's call SQLite! :-)) Re: Is there a One True	Postgresinterface? Is Ruby-postgresmaintained?

On Sun, 2008-05-25 at 22:29 +0900, Will Parsons wrote:
> > If the shoe fits.  I would use SQLite more if it had proper relational
> > algebra under its hood.
> 
> Would you mind explaining what you mean my that?

One example is that SQLite uses a very different typing system. In an
RDBMS (for SQL and every other definition of "relational" that I'm aware
of), every attribute has an associated type, and type checking is done
at the time the expression (SQL statement) is compiled.

In SQLite, you can store values of different types in the same attribute
in different tuples. This leaves us with the following undesirable
options:

1. Define every operator for every type.
2. Raise type exceptions at runtime when an operator is not defined for
the types of the input data.

If we choose #1, we end up with a language more like PHP, where values
are cast implicitly until it finds some way to return a result. This
completely circumvents type constraints, and it's easy to end up getting
a garbage result, and passing that garbage along through a series of
other operators until the source of the problem is thoroughly obscured.

If we choose #2, we introduce runtime errors that depend on the actual
data we have stored in the database. We can test the application and get
no errors for anyone, and then when we put it into production someone
may put some data of some type that is not supported by the operators
we're using for our queries. That may cause errors in many queries
throughout the system.

Both of these options are really just mechanisms to allow errors to
propagate further before they are caught. I think it's much better to
catch errors early, personally.

I have nothing against SQLite, in fact I think it's pretty good in some
ways, but I don't consider it to be a relational database.

Regards,
	Jeff Davis