
John Goerzen wrote:
On 2005-08-18, Brian Strand
wrote: I'm thinking about (re)writing some perl code in Haskell (for performance and correctness reasons). Has anyone done much with Oracle and Haskell? So far
Not Oracle specifically, but other databases, both free and proprietary.
Before I wade in too deep, I'm wondering if anyone has done much "business app" programming with Haskell (where "business app" is rather fuzzily defined as database access, web UIs, interfacing with various systems over ip, etc.). Does anyone have any advice? eg "don't go there" or "works great!" or "try OCaml" :) .
I'm doing a lot of it. There's a good deal of web and database activity going on here. Haskell is also my language of choice for scripting projects, especially data transfer (thanks in part to my FTP library in MissingH <g>)
I'm glad to hear that there are other people (or at least one other person, depending on what you meant by "here"...) doing this kind of thing; judging by the list traffic you'd think almost no one uses Haskell with a RDBMS.
I use HSQL for everything database-related. HaskellDB did not work out well. It proved rather buggy, cumbersome, inflexible (it appeared to be impossible to do a "SELECT" without "DISTINCT"), and poorly-scalable (try having it scan a database with several thousand tables).
HSQL is more low-level, but I'm comfortable with that, having used Perl's DBI and Python's DB-API before.
This (Perl DBI, ODBC, JDBC) is my background as well; if I can fire SQL at it, that's most of the way there.
HSQL natively supports the common Free databases (MySQL, PostgreSQL, SQLite, etc.) We use PostgreSQL for everything that we can. It's no less speedy than MySQL when correctly tuned, and far more reliable. It also seems to be a heck of a lot easier to install and work with than Oracle ;-)
Oracle is indeed a pain to install, although it has gotten better with recent versions. The main things keeping us on Oracle are its very good (online!) backup and recovery abilities, high-availability features, and fantastic performance tuning (the plethora of wait events and extremely detailed statistics is what I'm thinking of here). Performance-wise it has its strong and weak points.
... You didn't mention what platform you're on, but if you're on Windows, I'd imagine you'd have no problem making ODBC work. Unix is slightly more tricky, but again, I'd check out the unixODBC route. It's included in Debian by default, and I wouldn't be surprised if other OSs/distros have it too.
We run Suse 9.3 on x86 and x86-64; unixODBC does come out of the box here. If Takusen doesn't work out for some reason, I'll check into HSQL + unixODBC. Thanks for the advice, Brian