From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q0VF4i4v021218 for ; Tue, 31 Jan 2012 16:04:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkEAOoBKE/U4367jWdsb2JhbABDnhaQSiIBAQEBCQkLCRIFIoFyAQEEAW0BBAcFCwUGJSFFEgYTCQgBCYdhAwa5BosQLAYBKhMCgn4LAgIBBBMLBAZZCggDEwIKAgoEA4MsBI0uF5ow X-IronPort-AV: E=Sophos;i="4.71,596,1320620400"; d="scan'208";a="129559307" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail4-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2012 16:04:38 +0100 Received: from office1.lan.sumadev.de (dslb-188-097-001-058.pools.arcor-ip.net [188.97.1.58]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MYJ3F-1S5q4t17M9-00Vjib; Tue, 31 Jan 2012 16:04:38 +0100 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id 6AE7AC0714; Tue, 31 Jan 2012 16:04:37 +0100 (CET) Received: from 84.107.248.22 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Tue, 31 Jan 2012 16:04:37 +0100 Message-ID: <21fd4e0531483557870db6c2a97d2dec.squirrel@gps.dynxs.de> In-Reply-To: References: <1327835747.19516.23.camel@samsung> <1327868178.19516.60.camel@samsung> Date: Tue, 31 Jan 2012 16:04:37 +0100 From: "Gerd Stolpmann" To: "Diego Olivier Fernandez Pons" Cc: "caml-list" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V02:K0:Vg8bJSlr/1zZ9SXfvZLPB+wJzKGttpFQtVlt4yeybi2 okgQ4O7aOmmU98P4UBKhXpp8oeIeE/vI3Ita2tHOS7alpvG7n4 qUsySlJXfctrQv7NgrBu3TCFdV7MdizQXdLtUR8b8Mwg3H7jxF shNv1VSctnxrTHxUvS6KIzllZTvHgyAdYVS6rUxLpr9MBoSVnJ HyeJbZfefinfyTQmneIvrQoDy1b114zclrcpY5oV8KW8igFwny /1V81W2UL2bky/ke6kJieNDkIFe+m/kh19t2XsYPu0OT0gs+Tw GYqY5PMV+jy30184M3xVB1EFP02f4LMJ6B7hauktzWB6+eywg6 5l/Cetp4lQdrXyQaxU8bSWYstwu4YIHQJuXOR88eUGZEeGHEmN uf+Jnqs81/hRg== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q0VF4i4v021218 Subject: Re: [Caml-list] SQL engine in OCaml with client side cache > 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.