On Apr 9, 2009, at 1:28 PM, Jonas Sicking wrote:
On Thu, Apr 9, 2009 at 12:52 PM, Maciej Stachowiak <[email protected]>
wrote:
On Apr 9, 2009, at 8:19 AM, Boris Zbarsky wrote:
Giovanni Campagna wrote:
So why not adding a parameter on openDatabase() to specify what
kind
of database we want (and what kind of query language we will use)?
I mean something like
openDatabase(name, version, type, displayName, estimatedSize)
where type can be any string
so, for example, type = "sql" uses the standard SQL, type="sqlite"
uses SQLite extensions, type="-vendor-xyz" is a vendor specific
extension, etc.
How does this solve the original "no such thing as standard SQL,
really"
issue?
I agree that "no such thing as standard SQL" (or rather the fact that
implementations all have extensions and divergences from the spec)
is a
problem. But I am not sure inventing a brand new query language and
database
model as proposed by Vlad is a good solution to this problem. A few
thoughts
off the cuff in no particular order:
1) Applications are starting to be deployed which use the SQL-based
storage
API, such as the mobile version of GMail. So it may be too late for
us to
remove SQL storage from WebKit entirely. If we want this content to
interoperate with non-WebKit-based user agents, then we will
ultimately need
a clear spec for the SQL dialect to use, even if we also added an
OODB or a
relational database using some other query language.
2) It's true that the server side code for many Web sites uses an
object-relational mapping layer. However, so far as I know, very
few use an
actual OODB. Relational databases are dominant in the market and
OODBs are a
rarely used niche product. Thus, I question Vlad's suggestion than a
client-side OODB would sufficiently meet the needs of authors.
Rather, we
should make sure that the platform supports adding an object-
relational
mapping on top of SQL storage.
3) It's not obvious to me that designing and clearly specifying a
brand new
query language would be easier than specifying a dialect of SQL.
Note that
this may require implementations to actually parse queries
themselves and
possibly change them, to ensure that the accepted syntax and
semantics
conform to the dialect. We are ok with this.
4) It's not obvious to me that writing a spec for a query language
with
(afaik) a single implementation, such as jLINQ, is easier than
writing a
clear and correct spec for "what SQLite does" or some subset thereof.
Thus, I think the best path forward is to spec a particular SQL
dialect,
even though that task may be boring and unpleasant and not as fun as
inventing a new kind of database.
I tend to agree with Maciej here.
There's lots of competence and experience with SQL out there.
And do you know what they have been up to for the best part of this
decade? They have been hiding all the SQL under objects. Whether we
like it or not, that is the only way back-end developers can cope with
the fury and wrath of SQL. This is a cognitive type problem not just a
vocabulary problem.
I am going to attempt an analogy here, however atrocious it may sound.
Would it be any easier to explain 5 dimensions of quantum physics in
English than in Chinese? The problem is not vocabulary - it is just
cognitively hard. Same goes with SQL as well. Instead of burdening the
challenged (but smart) Web developer with understanding 27 different
way of expressing relations between data, it might be better to use a
limited subset that we can reliably, efficiently, and portably support
in any decent browser.
And
there's something to be said for the fact that SQL has proven itself
as a usable language at this point. I doubt that we could design a
language that cover as many use cases as well as SQL does. Though of
course we might be able to still be able to follow the 80% rule if we
design our own language.
I think this is a very important assumption we are making - just leave
it to a few elites to figure out what subset of SQL they can spec out
for the rest 6,790,062,216 of us - instead of finding out what 80% of
data access we require and whether a non-SQL approach that is better
tied to JavaScript would be better. This problem has baffled and
frustrated countless experts before us. Who among us here has
experience (first hand or second hand) to have subsetted SQL for any
previous standard?
But I definitely think that we need to define a strict SQL dialect to
use. One that will probably be stricter than SQLite currently is to
allow for easy implementation with other SQL backends.
/ Jonas
