Tim Soderstrom wrote:
Yo Jim!
I'm curious as to what your thoughts are in regards to the fact that
the standard isn't itself open? Correct me if I'm wrong, but
every-time something is added, removed, or changed in Drizzle in terms
of syntax, some guy that happens to have a copy of said standard has
to validate it? To me, in an open source world, that doesn't make any
sense.
I believe that older and draft versions are available for free. That
said, I don't think anyone has argued that drizzle implement every silly
feature that some company get pushed into the standard. There's a lot
of stuff there are vanity features, things badly thought out, design by
committee, etc.
My only point is that drizzle should not have *arbitrary* differences
from the spec. If you have update syntax, you should use the update
syntax from the standard unless there is an overriding reason not to.
Extentions are OK.
What is not OK is taking syntax from the standard (like identifiers) and
deciding your identifiers should behave differently. Maybe your rules
are better and maybe they are worse, but neither drizzle users nor
perspective drizzle users are well served with arbitrary differences.
Case in point. SQL triggers bay at the moon (having invented the
cascading trigger, this is something I have strong feelings about). So
in Netfrastructure, I ignored SQL standard triggers and implemented
Java-based triggers instead. But nobody is going to confuse the two.
It's a difference, but not an arbitrary difference.
The more difficult cases occur when you implement something that gets
standardized later (this is the only honor place for a database
developer). Then you have to deal with the hash the drones made of your
work and figure out how to converge. At Interbase, we innovated in GDML
and waited for the SQL committee to bless it before moving it into our
SQL. Unfortunately, that isn't a useful strategy anymore.
I know there's stuff in the official SQL standard that doesn't make
any practical sense. Implementing those would be, well, impractical :)
Drizzle's core is probably not going to need to worry about many of
these anyway since they are, if I remember correctly, in relation to
views, procedures, objects (I think?), etc. Alot of that seems like it
would be a pluggable module into Drizzle anyway.
See above.
So, while bucking the standard isn't a good idea in the grand scheme
of things, I think there could be times where it could make sense to
do so. The difference is that I think Drizzle's SQL standard should be
openly published and freely available for others to implement. In
fact, I'd say all the open source DB's and the DB platforms that care
should work on an Open SQL standard and adhere to that.
Sorry, but only an idiot bucks an international standard and declares
his alternative a de facto standard. There is no difference between
open source databases and commercial databases, except, perhaps, the
arrogance of the developers.
If you want to lead the world in features and functionality, go ahead
and innovate. If you're only playing catch up, you might as follow the
standard.
Note: It's sometime worth understanding the standard before diverging.
You might learning something. For example, you would have learned that
folding to lower case doesn't work for many languages.
Until we have an Open SQL standard, while inherently I agree with you,
I'm not so sure Drizzle needs to worry so much about the closed SQL
standard. Correct me if I'm wrong, but Drizzle is mostly compliant, or
at least will be depending on what people decide about those terrible
back-ticks. Any place were Drizzle deviates can't be by much since
Drizzle doesn't support a huge number of things from the standard in
the core. So if Drizzle is just a little off, I would think a simple
migration script would allow migrating to and from multiple DBs.
That's not ideal, but then again, neither is having to pay money for a
silly standard.
Look, I agree with you about paying for the standard. The SQL standard
was originally intended as a barrier to entry to the database market.
Bad idea, and it didn't work.
Let me make a suggestion. Why don't you think about ways to attract
potential users to drizzle rather than thumbing you nose at them? An
"open source database standard" would let you poach customers/users from
PostgresSQL. Why not raise you sights a little higher and endeavor to
poach users from Oracle or Microsoft?
$0.02
Tim
P.S. If I'm totally wrong about any of that, feel free to openly flame
away :)
See above.
On May 3, 2009, at 2:40 PM, Jim Starkey wrote:
At the risk of boring everyone to death, I'd like to explain a bit
more about why I continue to push a standard I don't like.
In the computer world, like many others, there comes a time where a
technology is good enough. At that point, something better has a
very high bar to acceptance. Yes, this leads to less than optimal
standards, but a good enough standard allows folks to concentrate on
newer and more interesting stuff. Lotus 1-2-3 was good, but not good
enough. Excel, on the other hand, is widely regarded as good enough,
sufficiently good that competing against it is pointless. X-11 is
another example. X-10 wasn't good enough, X-11 is. Sun's News and
display postscript were both better than X-11, but not sufficiently
better to bother with.
When the marketplace speaks, one should either listen or prepare for
a life a deep frustration.
SQL is clearly good enough. It had all sorts of competitors, all of
which are nearly forgotten. SQL won more or less fair and square --
there were multiple implementations of SQL, mostly incompatible, a
couple of implementations of QUEL, a couple of implementations of the
DEC/Interbase language, and any number of forgotten one-offs.
Due to pressure from users, the various SQL implementations have
gradually coalesced around an official standard. The process was
ugly and rigged, but the world spoke very clearly that it wanted a
standard database language, and those products that wished to ignore
the standard would be punished.
MySQL has an idea that it sets it own standard. This is not only
horseshit, but blatantly anti-democratic horseshit. It is the same
horseshit that Oracle and Ingres tried to pull with non-standard SQL
and QUEL -- languages that they controlled and the rest of the world
be damned.
The MySQL attitude toward SQL is stupid, ignorant, short sighted,
arrogant, and just plain wrong. Interoperability with the rest of
the world is important because it lets people use database software
to solve one set of problems so they can concentrate on other sets of
problems. Throwing roadblocks in front of users that both impede
acceptance of drizzle or MySQL and, not incidentally, prevent users
from converting to other systems, is profoundly unfortunate.
So, drizzle, join the world or thumb your nose at it and go your own
way. But please don't proclaim out of one side of your mouth that
you are a SQL database system and out the other that you aren't
willing to go beyond lip service to the standard.
When you have semantics beyond the standard, by all means go your own
way. Innovation should not be stifled by a standard. But if the
only motivation for divergence from the standard is to show the world
that you're smarter than everyone else (or, in the case of MySQL, too
dumb to fix it), give it up and get a life.
Let the counter-rants begin.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
