Re: [nodejs] Would SequelSphereDB (A JavaScript Relational Database) Work on Node.js?

[Daniel Rinehart]

The lack of licensing or cost information on the website leads me to
not even think about uses for the product.

-- Daniel R. <dan...@neophi.com> [http://danielr.neophi.com/]


On Tue, Oct 9, 2012 at 4:58 PM, John Fowler <john.f...@gmail.com> wrote:
> Hello Node.js gurus,
>
> I'm relatively new to Node.js, so please forgive the simplicity of this
> question: Would there be a use for a JavaScript Relational Database Engine
> like SequelSphere?
>
> SequelSphere is a new product to the HTML5 market that touts being it's own
> relational database engine including a SQL parser and execution engine. It
> is currently targeted at the client side of architecture to provide a
> mechanism for storing relational data (since the WebSQL standard was
> abandoned). Since it has it's own SQL engine, it truly works cross-browser,
> and it persists its data via localStorage and indexedDB.
>
> However, I'm assuming that since Node.js runs on the server, that it would
> have a whole host of much more mature relational database technologies to
> choose from. But is there a beneficial factor in SequelSphere being 100%
> JavaScript?
>
> Can someone tell me what use SequelSphereDB may have with Node.js? Why
> would someone want to use SequelSphere rather than a much more mature
> server-side native relational database?
>
> Thanks!
>
> john...
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Ted Young]

I also have the caveat that I would never use a proprietary database.

If you could show that it was faster or more portable than sql-lite, maybe because you didn't have to make the hop to C, then maybe it would be useful.  But I don't see why this would be an improvement over just using SQLite bindings, if you had the kind of problem SQLite solves. 

If you wanted to run the same code on the server as on the client, not having to change your interface would be useful.  But most cases where you're running code in a browser and also want to run it on the server, you don't want to be using SQLite on the server.  A better solution would be to allow users to write their own persistence layer, and provide adapters for all the mainstream db's.

 

Ted

[John Fowler]

Daniel,

That's a very fair statement.  Being intimately associated with SequelSphere, I've taken this feedback and made a few modifications to the website to reflect the fact that it is free for development & testing along with small applications.  Complete licensing and cost information is only available for people after logging in. 

The target audience for SequelSphere is mid to large companies and corporations:  those entities that have in-house application developers who are much more comfortable with storing data in a relational database, and simply want a product that will just "handle it", including the persistence to the local client. These developers are usually quite adept as making webservices and getting data to & from the client, but frequently would prefer a simple mechanism such as SQL on the client end for querying, aggregating, and manipulating data.

Hope this helps,

john...

PS.  In case you are interested, I've also posted a bit more documentation on the website concerning how it can be used.

[John Fowler]

Ted,

You made a number of really good points, and I think you've echoed many of my thoughts very well.

Concerning the browser: the reason SequelSphere works so well on the client is that it is truly 100% JavaScript, and thus will run on _any_ browser and platform.  I've shown it executing SQL beautifully on some of the ugliest and oldest browsers and platforms around.  Albeit, it can't persist data locally on the browser unless the browser supports "localStorage" or "indexedDB", or some other local persistence mechanism, but it still provides a manner for applications to execute SQL dynamically at the point of the client.  Nowadays, of course, almost all browsers mobile, desktop, or otherwise support "localStorage", and so SequelSphere can persist data locally as well.

Concerning SQLite:  That does require a client install that SequelSphere does not.  That makes SequelSphere much more portable.  It is installed like any other JavaScript library:  via a <script> tag in a webpage.  No other client software is required.

For the Server, that is where my question lies.  Even though I'm a big proponent of SequelSphere, I recognize that the Server-Side Relational database technologies (Oracle, DB2, MS SqlServer, MySql, SqlLite, etc) are always going to have some significant advantages over a purely JavaScript relational database.  Being able to go "native" will get you some speed and size that the constraints of JavaScript just can't get past.  (PLEASE CORRECT ME If I'm wrong here)  As such, even I think the main pattern would be to have webservices fronting a traditional database, serving and syncing data to and from the client.  On the client of course, SequelSphere then makes tremendous sense.

However, my mind is still trying to figure out if there would be some benefit to having the _same_ product on the client & the server.  Perhaps there could be some synchronization optimizations, or some usability patterns that otherwise would not be available.

Thanks for helping me think,

john...

[John Fowler]

Ted:

One more excellent point you made that I forgot to confirm:  SequelSphere does allow users to write their own persistence layer.  It also allows fairly simple and straight-forward integration with all backend datastores (relationally or not) through the use of JSON.  That is, the database can easily import tables and their data from JSON objects, and it can export data as JSON objects (from a result of a SQL query).

There are also low-level SequelSphere APIs (as-of yet undocumented) for allowing other client-side classes or storage mechanisms to be tables that participate in queries.  As such, many of the RIA frameworks that provide their own persistence layers could actually have their data queried via SQL.  SequelSphere is in the process over the next several months of creating some of these "connectors" to allow close bindings between RIA frameworks.

Anyways, this isn't strictly Node.js stuff, so I'll shutup about it.

On this forum, I'm much more interested in how SequelSphere could be used effectively on Node.js.  Since no "native" code is required, would it allow cloud-based databases to be easier to migrate and propogate?  

Please provide any comments or ideas you have...

Thanks,

john...

On Thursday, October 11, 2012 3:02:33 PM UTC-5, tedsuo wrote: