Re: [Caml-list] SQL engine in OCaml with client side cache

["Gerd Stolpmann" <info@gerd-stolpmann.de>]

>     Caml-list,
>
> [Gerd Stolpmann wrote]
>> The SQL server "solves" this by deciding on a query strategy beforehand.
>
> What ??? I thought SQL servers shipped on-the-fly optimizing compilers
> that would evaluate the query and use some heuristics (like table size
> and density) to decide in which order to execute the loops + learning
> on sequences of queries + on-the-fly reindexing.

Yes, but this happens before the query is executed. Once the execution
starts, the plan is not changed anymore.

> [Gerd Stolpmann wrote]
>> (Just as I side note: Missing scalability has always been a problem for
>> SQL databases. Currently, many companies go away from this technology
>> for their giant data warehouses just because of this. Of course, these
>> are not read-only, but read-write, but even having read-only scalability
>> would be a big achievement.)
>
> Mmm... I thought relational databases were a universal object, in the
> mathematical sense meaning any other object maps into them. What do
> they use if not relational databases ?

Well, this is the NoSQL world (=not-only SQL). In short:

 - You accept that you store data in non-normal form. In SQL
   the preferred model is to store one information only once,
   and to do all joins at query time. In NoSQL it is usual to
   repeat information to avoid joins, even if this means that
   updates become more complicated.
 - On the technology side, you use alternate data stores like
   distributed key/value stores or column-based stores. At
   least at query time.
 - For preparing data, one of the new technologies is map/reduce.
   Basically it's a massively scalable form of sorting data.

Of course, this is all not as universal as the good old SQL world.
Especially it is a non-match for OLTP. But if you can separate data
preparation from data querying, it's an option that opens the door to
almost infinite scalability. It's what the web-2.0 companies use.

>> And an ugly parser :-(
>
> You don't seem to like SQL much, which is surprising as it is kind of
> isomorphic to comprehension of sets (of tuples). That's why F# added
> first class SQL support with comprehension-like syntax
> http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110).aspx

I did not say that I dislike SQL. It's still the most important DB
technology, and often it is the only choice we have. And you are right, it
is about set operations. Nevertheless, the syntax has strange aspects
(e.g. no reserved words, or that you cannot nest SELECTs arbitrarily, e.g.
(SELECT ... UNION SELECT ...) INTERSECT SELECT ...). The best thing is
that it is standardized.

The F# syntax is interesting (I frequently thought about integrating SQL
as DSL into Ocaml best, and did not find any good solution).

> The idea being probably that on top of a certified whole-program
> optimizing compiler, pattern matching optimizer, multi-core capable
> garbage collector and generalized lexing/parsing library, functional
> language implementers will also have to write an optimizing SQL /
> comprehension engine.

Yeah, an attempt to raise the bar.

Gerd

>
>         Diego Olivier
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.