SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)

Ben Sizer kylotan at gmail.com
Fri Sep 8 10:47:53 CEST 2006


mensanator at aol.com wrote:
> Bruno Desthuilliers wrote:
> > SQLite never pretended to be a full-blown RDBMS - just a lightweight
> > simple embedded database as SQL-compliant as possible.
>
> Ah, *you* haven't read the documentation either!
>
> "as SQL-compliant as possible"?
>
> ROTFLMAO!

No need to be rude really. In this context "as SQL-compliant as
possible" means, "as SQL-compliant as it is possible to be within the
project's restrictions", which presumably refer to code size and speed.
It's a reasonable trade-off.

> **********************************************************
> * The authors argue that static typing is a bug in the   *
> * SQL specification that SQLite has fixed in a backwards *
> * compatible way.                                        *
> **********************************************************
> </quote>
>
> "Fixed"? Up until now, I didn't think it was possible for
> crackpot theories to be implemented in computer science.
> This is absolutely the craziest thing I've ever heard.

It's not a crackpot theory. It's a completely reasonable theory. SQL is
based on relational algebra, which provides a mathematical set of
operators for grouping data that is stored in separate sets. That data
is selected and projected according to its value, and nothing else. The
concept of it having a 'type' has been overlaid on top of this,
presumably to facilitate efficient implementation, which tends to
require fixed-width rows (and hence columns). It's not necessary in any
sense, and it's reasonable to argue that if it was trivial to implement
variable width columns as efficiently as fixed width columns, that
explicit data types might never have needed to exist.

> So much for
> "If switching to a larger database such as PostgreSQL or Oracle
> is later necessary, the switch should be relatively easy."

If you rely too much on a language-enforced data type rather than the
values of the underlying data, perhaps Python is not for you!
Personally I've migrated from SQLite to MySQL a couple of times (on
small projects, granted) and not found it to be a problem at all.

> Fixing the documentation is now becoming an enormous task.

I don't think so... it doesn't take much to say that the module
implements a subset of SQL but stores ignores data types.

> What are the chances that anything I send in as a bug report
> will simply be ignored? Kind of like the Emporer's New Clothes, eh?
> It would be an admission of ignorance and stupidity on the part
> of the Python Development Team, wouldn't it?

Why get so bitter over this? I agree the docs need fixing but you make
it sound like this was a deliberate attempt to make you waste your
time.

-- 
Ben Sizer




More information about the Python-list mailing list