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. :-)
Received on Wednesday, 27 October 2010 10:57:13 UTC