Re: Replacing WebSQL with a Relational Data Model.

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

> >rather than a standard or anything that needs support from browser
> vendors.
>
> An implementation of the relational algebra would be ideal for
> standardisation as it is:
>
> - complete
> - mathematically sound
> - has a minimal API (the minimum number of API objects to implement a
> complete system).
> - can be formally defined, with definitions derived from the definition of
> relational algebra.
>
> I believe the best use of this API will be as a replacement for WebSQL,
> allowing a database engine like SQLite or MySQL to be used to provide the
> functionality. Such use does require standardisation and implementation in
> the browsers. IndexedDB is not a replacement for WebSQL at the moment, and
> even with joins, I don't think it will compete with a dedicated database for
> performance (when dealing with real world queries with joins, compound
> indexes etc...)
>

Like we've said, you're free to write any spec you'd like.  When we're ready
for joins in IndexedDB, I'm sure it'd at least be considered.  It's not
worth talking about yet though.  We have more pressing issues.


> I am interested in implementing a relational layer on top of IndexedDB for
> educational purposes and to help get something standardised, but I don't
> think anyone would consider a small relational DB layer in JavaScript a
> serious alternative to a decent relational database backend.
>

The primary goal of IndexedDB is to make use cases possible.  We definitely
try to make things more usable when it's not adding too much surface area,
but we're primarily here to create a storage primitive.  Libraries that make
things more usable and which add functionality are great and encouraged.

If I were writing a large project on top of IndexedDB, the first thing I'd
do is look for libraries on top of it.  And if there wasn't one, I'd
probably look at writing one.


> What exactly have the MySQL / SQLite / PostgreSQL / MS SQL Server / Oracle
> developers been doing all these years? Do we seriously expect to compete
> with something written in JavaScript?
>

Those engines are way too complex to be added to the web platform and they
aren't interoperable.  Full time DBAs are needed for anything other than the
most basic setups, and the tweaking is very complex and hardware and DB
engine dependent.  If we ever get to that point with IndexedDB, we've failed
web developers.

Once we're happy with our first iteration, we'll start looking at adding
more features.  I'm pretty happy with where we're headed for a first
iteration though.


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

> Hi,
>
> Just want to pick up on this point:
>
> >down to how queries are optimized.  The latter part is very worth noting
> because this is the primary reason SQL
> >code is not easily portable between engines.  Sure it'll run, but it won't
> run fast.  Given how long SQL's been
> >around and the fact that different engines optimize very differently, I
> don't think you can practically argue this
> >isn't an issue.
>
> 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.)

J