Re: Replacing WebSQL with a Relational Data Model.

I have a feeling modern relational databases do this automatically (have
separate storage for BLOBs), to keep table streaming fast...

IndexedDB access for aggregate operations (sum, average, standard deviation)
is going to be poor as walking the tree will involve many more disk seeks.
So the coder will need to be aware that such operations are slow, and that
requires understanding how a B-Tree works.

Of course doing things different ways is going to result in speed
differences. If you use a bubble sort its slower than a quick sort, and
thats slower (on real hardware) than a funnel sort.

Such issues can easily be dealt with in the standard... One line of advice,
"Large objects should not be stored using the relational API, use IndexedDB
instead, and store a reference in the relation".


Cheers,
Keean.


On 27 October 2010 11:56, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Wed, Oct 27, 2010 at 11:42 AM, Keean Schupke <keean@fry-it.com> wrote:
>
>>
>>
>>> Why would LocalStorage be involved at all?  Just keep the data in an
>>> ObjectStore.
>>>
>>
>>
>> Sure, why not. I guess this is an SQL habit. Generally I don't put large
>> blobs of data into the tables. The point being if its not going to be part
>> of a query why is it in the table?  With a relational database the rows are
>> stored sequentially (indexed are external and only apply to some columns),
>> so scanning is faster (for example summing a value across all rows can do a
>> streaming read of the table so is faster than tree walking a B-Tree index),
>> but a large blob in each row would result in more disk seeks.
>>
>> This kind of single access pattern is not really a database at all, and is
>> ideal for an IndexedDB implementation. Where the relational model, and SQL
>> come into their own is where you have several different queries with
>> different access patterns that all need to be fast.
>>
>
> No matter what the API looks like for structured storage on the web, it's
> important that we abstract implementation details like this away from the
> user.  They shouldn't have to think about how to optimize the on-disk
> structure.  Because, frankly, most won't.
>
> J
>
> P.S. At least FireFox and WebKit store all LocalStorage data in SQLite
> rows.  :-)
>