Re: 'Pure' client-side javscript database?

"Richard Cornford" <Richard@litotes.demon.co.uk> wrote in message
news:deqovc$sbr$1$8300dec7@news.demon.co.uk...
> cjl wrote:
>> I know that it is silly in the age of Google to 'lose' something on
>> the internet, but I recently checked out a project that had
>> implemented a database with a subset of SQL in pure client-side
>> javascript.
>
> A client-side database? Now there is a spectacularly bad idea. The last
> thing you want to do is have the client download an entire database just
> so it can extract a tiny part of it. Server-side is where the database
> belongs, and where the task of extracting data from it should happen.

Although I agree with you in general I think there are many scenarios where
this could be useful. It really depends on the data in question and the
circumstances of its use, I think.

For example I've worked for the past 10 years or so on a large public
festival here in Boston. The one-day long event features about 200 artists
appearing at 60 or so venues. The basic data set: Artist, a short
description, performance times, categories and venues is, perhaps, 75-100kb.
Here's the page from last year's event:

http://www.firstnight.org/Content/NewYears/Artists/Explore/Index.cfm

Now in this case the site is a non-profit and the server is slow (donated).
However the event is popular: we get several hundred thousand requests
between 10 and 12 on the morning of the event - this can start to drag
things down. The most popular way to search is to visit several slices
(certain categories, times or venues) and create a list of those things
you're interested in.

Now... downloading just the data and client-side application to display
would be larger than downloading just those pages: but when compared to two
or three requests for subsections of data (which our metrics show is
average) it would be smaller and much, much faster. The server would also
be getting a much desired break because it would be, essentially, passing
down static content which would enable much the same functionality.

Of course there's also no reason that the database has to be "whole"...
passing down predicitve data can make for a much more usuable interface.
For example a site which displays television schedules might actually
display only a two hour slice of data... but passing down four hours in the
assumption that the users will want to see "what's on next" seems a safe
bet. In this case the two hours worth of data could be passed down and page
displayed. However, in the background the next two hours could be getting
fetched and added to the client-side database.

At the very least, even without predictive caching, the data already
displayed could be maintained in the client-side database in case the user
wants to go back to it (not uncommon, I would think, for television
listings).

Now I wouldn't consider doing this on the site I referenced - there's just
too much need for support across browsers and situations. However as an
example I think it holds. I could see other situations where it would be
useful: trade show schedules (where saving the web page would allow for
offline use of that version of the schedule) and other small datasets.

However there are definately some intranet projects that this would fit
excellently in.

But it's definately not for everything. In my mind the dataset would have
to be small enough such that the whole dataset and all the code to
manipulate it would be smaller than the total amount of code passed down in
a session of using the server-side data. It would also have to data that
will most likely be used as a whole - as you said there's no sense in
passing down a whole rabbit if you just want that lucky foot.

I think, like anything, the descision to add this complexity to the
client-side would have to logically defensible - and in most cases it just
isn't.

Jim Davis
Received on Tue Oct 18 03:14:03 2005