2009/7/9 Günther Schmidt <[email protected]> > Hi, > > I'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 "source" data of > other queries and queries can't themselves be indexed for further efficient > querying. Since the amount of data could become rather large, in-memory > processing wasn't an option and I thus chose SQL (Sqlite). > > The solution works, but still I'm not quite happy about it, since I > consider the tables that hold intermediate results fixes. > > 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? > > Günther >
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't much middle ground between getting almost no type protection and having to keep a bunch of HLists around to make sure you don't reuse a dimension attribute in a query incorrectly. As for interfacing with 3rd party OLAP cubes, I haven't heard of anyone having been masochistic enough to build an interface to something like ADO MD from Haskell. -Edward Kmett
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
