Re: Replacing WebSQL with a Relational Data Model.

On Tue, Oct 26, 2010 at 2:50 PM, Keean Schupke <keean@fry-it.com> wrote:

>
>>> I disagree, and I will argue the point. I don't see an argument for
>>> including optimisation strategies in a standard here. All DB engines make a
>>> good job of optimising most queries. I have written SQL for Oracle,
>>> Microsoft SQL Server, PostgreSQL, MySQL, and SQLite, and this has never been
>>> a problem. More likely bad performance is due to a bad schema and a bad
>>> design.
>>>
>>
>> This directly contradicts my personal experience and what I've heard when
>> talking to DBAs.  If you read any book on optimizing SQL, you'll find that
>> the majority of optimizations for one engine will actually slow things down
>> in another.  And this is sometimes true even between different versions of
>> the same database.  (All of this is especially true of MySQL and SQLite.)
>>
>
> And this directly contradicts with my personal experience... and I have
> used SQLite extensively on the mobile platforms, and we just design the
> schema's and write the queries.
>
> For example take the FarmDB query from my earlier email:
>
> UPDATE Animal
>    SET Animal.location=42
>  WHERE Animal.animalid IN
>          SELECT Contaminated.animal
>            FROM Contaminated,Animal
>           WHERE Animal.type='cow'
>            AND Contaminated.type='BSE'
>            AND Animal.animalid=Contaminated.animal;
>
> This will run fine on all those databases with no changes or optimisations.
> That is what the query optimiser is for. You just write the query in the
> obvious way, and let the DB take the strain of optimising it. Even the worst
> performing of those databases is going to do a better job of optimising this
> query than _anything_ you or I could come up with, without investing many
> man-years of research and development.
>
> Do you think we can outperform either MySQL or SQLite with JavaScript code
> running in a web-browser? Even the slowest most un-optimised query will be
> better that that.
>
> To me this seems an idealist and impractical argument. We don't want a fast
> solution (faster than coding in JavaScript) because one implementation may
> be faster than the other?
>

I'm saying this is one of the problems with WebSQLDatabase and something
that'll need to be taken into consideration when we spec any query language
for IndexedDB.

Coming up with a join language for IndexedDB is far from the top of our
priority queue at the moment.  If you're interested in doing some
prototyping or speccing on your own in the mean time, I think that'd be very
valuable.  But either way, I don't think we should spend much more time
discussing this issue at this time.

J