From: Diego Olivier Fernandez Pons <dofp.ocaml@gmail.com>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] SQL engine in OCaml with client side cache
Date: Sun, 29 Jan 2012 19:29:10 +0100 [thread overview]
Message-ID: <CAHqiZ-LCQFKuuMVtL_WAbUOMVKfBg4vg45OCVZoSmryi5+Az6g@mail.gmail.com> (raw)
In-Reply-To: <1327835747.19516.23.camel@samsung>
Caml-list,
[Gerd Stolpmann wrote]
> I think this is not possible. SQL always needs access to the complete
> table for executing queries (including the complete indexes).
I am surprised by your comments. Many systems have two-layer data
storage (massive but slow one, fast but limited one), and that doesn't
affect their semantics. Consider a compiler (heap/ registers), an
operating system (swap files, RAM) or even a typical SQL database that
keeps tables in memory for fast access.
This is the same but the hard drive is on the server side, the RAM on
the client side and they communicate by Internet.
I am not saying that implementing a generic cache / swapping system
for an SQL database is easy. That's why I added that for this specific
application I can easily compute a superset of the data the user will
need. Lets take an example : say my database contains sales history
data for a convenience store chain for all stores in France, all
products for last 5 years. If my user is the Coca-Cola replenishment
manager in Paris, he only needs sales of Coca-Cola products for the
last 5 similar days for each store in Paris. Thereafter I can generate
a query on the server that sends that superset of data to the client
and let the SQL client engine work on that.
I may have underestimated the amount of work to be done, because I
thought this would be on the easier side.
My idea was the following
Server side
- 3rd part SQL database
- OCaml bindings
- Web communication interface
Client side
- SQL parser written in OCaml + interpreter
- control system to guess superset of data and request from server
- Web communication interface
- output to JavaScript widget toolkit
I was expecting to find most of the pieces already done and only
having to glue them. I was actually more afraid of the JavaScript part
than the SQL one... You can even find SQL engines written in
JavaScript out there, to run in a web browser like Jade
http://jacwright.com/489/in-memory-javascript-database/ or JOrder
(JSON) https://github.com/danstocker/jorder
At the end that's nothing but arrays and for loops.
Diego Olivier
next prev parent reply other threads:[~2012-01-29 18:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-29 9:56 Diego Olivier Fernandez Pons
2012-01-29 11:15 ` Gerd Stolpmann
2012-01-29 18:29 ` Diego Olivier Fernandez Pons [this message]
2012-01-29 20:16 ` Gerd Stolpmann
2012-01-29 23:26 ` Diego Olivier Fernandez Pons
2012-01-30 9:12 ` Gabriel Scherer
2012-01-31 15:04 ` Gerd Stolpmann
2012-01-29 11:39 ` Marc Weber
2012-01-29 13:42 ` Daniel Bünzli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHqiZ-LCQFKuuMVtL_WAbUOMVKfBg4vg45OCVZoSmryi5+Az6g@mail.gmail.com \
--to=dofp.ocaml@gmail.com \
--cc=caml-list@inria.fr \
--cc=info@gerd-stolpmann.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox