From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q0TNQnwJ027488 for ; Mon, 30 Jan 2012 00:26:49 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoCAH/VJU9KfVK2kGdsb2JhbABDrlIIIgEBAQEJCQ0HFAQhgXIBAQEDARICLAEbEQUHAQMBCwYFCwM4IgERAQUBHAYbGodaCZtZCotqgm+Dfz+IcQIFC4gpAwEJAgIECgIBDAQDBAE7AwuEEwMaAgEGgz8ElRqOFT2EAA X-IronPort-AV: E=Sophos;i="4.71,589,1320620400"; d="scan'208";a="141952349" Received: from mail-we0-f182.google.com ([74.125.82.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Jan 2012 00:26:44 +0100 Received: by werm13 with SMTP id m13so1973204wer.27 for ; Sun, 29 Jan 2012 15:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mW+Jt2HkIb7EmifFcF0Gs6daxdJEd1eWbsFglLxXfEc=; b=w4pwY+DajmZVRKfF9LZ3+iJL4duXuThBTky+p4Q9QQfgjuCz1dCwwjTNeiy9XW5gzz BMzWUj7h2VXBjmTXcolp7riRCHvspuWmsL3gy5+6ObUg5+UwRIgOXgBxzCw5cJva/EPO KuRZSv34EgJePelRqrGftaws/KVlIsCEdsIpo= MIME-Version: 1.0 Received: by 10.216.132.32 with SMTP id n32mr2811974wei.41.1327879603964; Sun, 29 Jan 2012 15:26:43 -0800 (PST) Received: by 10.216.51.207 with HTTP; Sun, 29 Jan 2012 15:26:43 -0800 (PST) In-Reply-To: <1327868178.19516.60.camel@samsung> References: <1327835747.19516.23.camel@samsung> <1327868178.19516.60.camel@samsung> Date: Mon, 30 Jan 2012 00:26:43 +0100 Message-ID: From: Diego Olivier Fernandez Pons To: Gerd Stolpmann Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 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. [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 ? > 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 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. Diego Olivier