Re: use LL(1) or LALR(1) for JavaScript SQL interpreter?

"Eric" <englere_geo@yahoo.com>
11 Nov 2006 21:31:26 -0500

          From comp.compilers

Related articles
use LL(1) or LALR(1) for JavaScript SQL interpreter? petermichaux@gmail.com (Peter Michaux) (2006-11-11)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? englere_geo@yahoo.com (Eric) (2006-11-11)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? petermichaux@gmail.com (Peter Michaux) (2006-11-13)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? JustinBl@osiristrading.com (excalibur2000) (2006-11-15)
Re: use LL(1) or LALR(1) for JavaScript SQL interpreter? englere_geo@yahoo.com (Eric) (2006-11-15)
| List of all articles for this month |

From: "Eric" <englere_geo@yahoo.com>
Newsgroups: comp.compilers
Date: 11 Nov 2006 21:31:26 -0500
Organization: Compilers Central
References: 06-11-050
Keywords: SQL, practice

Peter Michaux wrote:


> My goal is to write an database management system (DBMS) in JavaScript
> so that other JavaScript in a browser can manipulate a lot of data
> easily using a small subset of SQL.


This is a terribly bad idea. JavaScript is interpreted, and would be
way too slow to handle the job you're asking it to do. Also, web
browsers slow down to a crawl when you load too much data into them
for a particular page. You'll also see a lot of errors if you really
push the limits.


Why not keep the data on the server and query it from the browser?
Something like MySQL is plenty good for this purpose. Use php on the
server as your scripting language to interact with the DB - php is
very easy to use for this purpose. Only HTML/CSS/JavaScript goes down
to the browser. But the JavaScript should only have the purpose of
sevicing the UI. It's just plain not fast enough for much else. And
JavaScript can't write to the local hard disk, of course (except
perhaps for isolated storage, depending on the browser).


Eric



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.