Re: Web Storage & SQL

On Apr 9, 2009, at 1:28 PM, Jonas Sicking wrote:

> On Thu, Apr 9, 2009 at 12:52 PM, Maciej Stachowiak <mjs@apple.com>  
> 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
>

Received on Thursday, 9 April 2009 20:57:00 UTC