Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- From: "mensanator@xxxxxxx" <mensanator@xxxxxxx>
- Date: 8 Sep 2006 14:08:12 -0700
Ben Sizer wrote:
mensanator@xxxxxxx 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
.
- Follow-Ups:
- Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- From: Paul McNett
- Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- From: Marc 'BlackJack' Rintsch
- Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- From: Steve Holden
- Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- References:
- Is it just me, or is Sqlite3 goofy?
- From: mensanator@xxxxxxx
- Re: Is it just me, or is Sqlite3 goofy?
- From: Bruno Desthuilliers
- SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- From: mensanator@xxxxxxx
- Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- From: Ben Sizer
- Is it just me, or is Sqlite3 goofy?
- Prev by Date: Re: best split tokens?
- Next by Date: egg and modpython
- Previous by thread: Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- Next by thread: Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
- Index(es):
Relevant Pages
|
