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

[mensanator at aol.com]

George Sakkis wrote:
> mensanator at aol.com wrote:
>
> > Sure, errors happen with static typing. After all, the values still
> > have to match. Dynamic typing allows for more potential errors and,
> > thanks to Murpy's Law, I will have a much bigger problem with data
> > integrity.
>
> If this was a java or c++ list, all this rant would be more
> understandable, but bashing dynamic typing in a dynamic language list
> seems pointless at best (as this has been beaten to death over and over
> again), flamebait at worst.

But I'm not bashing Python's use of dynamic typing. But if the
SQL Language Specification says static typing, then static typing
it is. Period.

> It should be clear by now that there are
> two (at least) alternatives:
> 1. Validate the data in python before (or at the same time when)
> feeding the DB.

Data integrity is an issue even with static typing. It's a bigger
issue with dynamic typing.

> 2. Forget sqlite and use a statically typed DBMS; it's not like there
> is a shortage of them.

I have no intention of forgetting sqlite simply because it's
now part of the standard library. I have now qualms about
using it *now* because I understand it better. But reaching
that level of understanding was like pulling teeth.

Documentation shouldn't talk down to the reader. It's always
bad when you confuse the smart people. The ignorant are
supposed to be confused. It's job of the documentation to
educate the ignorant. Hiding the idiosynchrocies of Sqlite3
from the user who's already familiar with SQL is simply
unacceptable.

>
> Massaging your SQL statements to make up for the lack of type checking
> (even if this is always possible)  would be a bad idea for more than
> one reasons (complexity,portability,performance), so you'd better not
> go down this road.
> 
> George