<div class="gmail_quote">2009/7/9 Günther Schmidt <span dir="ltr">&lt;<a href="mailto:gue.schmidt@web.de">gue.schmidt@web.de</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
I&#39;ve developed this commercial app in Haskell with all of the business logic coded in SQL with the help of haskelldb. Some of the intermediate results (of queries) I had to manifest in extra tables because the initial query was expensive, the intermediate result would be the &quot;source&quot; data of other queries and queries can&#39;t themselves be indexed for further efficient querying. Since the amount of data could become rather large, in-memory processing wasn&#39;t an option and I thus chose SQL (Sqlite).<br>

<br>
The solution works, but still I&#39;m not quite happy about it, since I consider the tables that hold intermediate results fixes.<br>
<br>
I understand that the financial industry employs Haskell to analyse large data set under complex schemes. I wonder what techniques are employed for that, do they use Haskell to create some sort of OLAPish tools? Do they use Haskell to run complex queries against SQL data warehouses?<br>

<br>
Günther<br></blockquote></div><br><div>A couple of years back when I was forced to learn MDX in excruciating detail, I wound up building a little Haskell DSL for manipulating small OLAP-like datasets; I never really liked the API though, and the embedding was pretty weak, because there wasn&#39;t much middle ground between getting almost no type protection and having to keep a bunch of HLists around to make sure you don&#39;t reuse a dimension attribute in a query incorrectly.</div>
<div><br></div><div>As for interfacing with 3rd party OLAP cubes, I haven&#39;t heard of anyone having been masochistic enough to build an interface to something like ADO MD from Haskell.</div><div><br></div><div>-Edward Kmett</div>