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 
<http://www.sequelsphere.com/>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...


On Thursday, October 11, 2012 3:02:33 PM UTC-5, tedsuo wrote:
>
> 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
>  
> On Oct 9, 2012, at 4:27 PM, Daniel Rinehart <[email protected]<javascript:>> 
> wrote:
>
> The lack of licensing or cost information on the website leads me to
> not even think about uses for the product.
>
> -- Daniel R. <[email protected] <javascript:>> [http://danielr.neophi.com/
> ]
>
>
> On Tue, Oct 9, 2012 at 4:58 PM, John Fowler 
> <[email protected]<javascript:>> 
> 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 [email protected] <javascript:>
> To unsubscribe from this group, send email to
> [email protected] <javascript:>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> -- 
> 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 [email protected] <javascript:>
> To unsubscribe from this group, send email to
> [email protected] <javascript:>
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
>

-- 
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to