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

[mensanator at aol.com]

Ben Sizer wrote:
> 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.

And I accept those restrictions. I haven't complained about SQLite
being a subset of SQL. It's just that it's not SQL, so it can't even be
a subset.

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

Ok, it's not crackpot with respect to relational algebra.

> 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

But they do exist as far as the SQL Language Specification is
concerned. Isn't this just like the parallel postualate in Euclidean
Geometry? Sure, the parallel postulate isn't absolute truth in
geometry theory, but once you make it an axiom, then calling
it a bug and trying to fix it while claiming it's still Euclidean
Geometry is crackpot math.

If the SQLite author wants to make a new system based on a
different set of relational algebra axioms, that's fine. But claiming
the SQL Language Specification axioms are "bugs" that need to be
"fixed" is crackpot.

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

Suppose someone said "this is a new implementation of Python".
And all your programs crashed in it. Then, buried deep inside the
documentation (so as not to affect sales), you find that the author
has an issue with dynamic data types and in HIS version of Python,
all data types are static. Wouldn't you argue that what he has
isn't Python?

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

And yet, I, knowing how SQL is supposed to work, had all
kinds of problems. Why do you think I started this thread?
Because the kind of things that work in SQL-compliant systems
weren't working in SQLite.

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

So I can't just say

WHERE qty=12

I have to say

WHERE (qty=12) OR (qty="12")

otherwise I can't guarantee that my query will return the records
I want. Oh, and that will cause a Type mis-match error in
MS-Access meaning I literally can't migrate this query from
SQLite to MS-Access (or any other SQL-compliant database).

Do you know what INNER JOIN means?

Do you know how important it is to a relational database?

Can you explain how an INNER JOIN can even work, in theory,
with dynamic data types?

The implications of violating the SQL Language Specification
are much more serious than you think.

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

I'm not bitter, just being a squeaky wheel.

And I'd be more than happy to make PROPER corrections to the
docs if I thought the effort wouldn't be wasted. But in looking over
this thread, it certainly appears that there are very few who
understand the issue.

> 
> -- 
> Ben Sizer