Is Functional to Relational mapping easier than Object to Relational?

Question

Object-relational mapping has been well discussed, including on here. I have experience with a few approaches and the pitfalls and compromises. True resolution seems like it requires changes to the OO or relational models themselves.

If using a functional language, does the same problem present itself? It seems to me that these too paradigms should fit together better than OO and RDBMS. The idea of thinking in sets in an RDBMS seems to mesh with automatic parallelism that functional approaches seem to promise.

Does anyone have any interesting opinions or insights? What's the state of play in the industry?

Answer 1

I'd guess functional to relational mapping should be easier to create and use than OO to RDBMS. As long as you only query the database, that is. I don't really see (yet) how you could do database updates without side effects in a nice way.

The main problem I see is performance. Todays RDMS are not designed to be used with functional queries, and will probably behave poorly in quite a few cases.

Answer 2

I'd think that, as Sam mentioned, if the DB should be updated, the same concurrency issues have to be faced as with OO world. The functional nature of the program could maybe be even a little more problematic than the object nature because of the state of data, transactions etc of the RDBMS.

But for reading, the functional language could be more natural with some problem domains (as it seems to be regardless of the DB)

The functional<->RDBMS mapping should have no big differences to OO<->RDMBS mappings. But I think that that depends a lot on what kind of data types you want to use, if you want to develop a program with a brand new DB schema or to do something against a legacy DB schema, etc..

The lazy fetches etc for associations for example could probably be implemented quite nicely with some lazy evaluation -related concepts. (Even though they can be done quite nicely with OO also)

Edit : With some googling I found HaskellDB (SQL library for Haskell) - that could be worth trying?

Answer 3

The hard problems of extending the relational database are extended transactions, data-type mismatches, automated query translation and things like N+1 Select that are fundamental problems of leaving the relational system and -- in my opinion -- do not change by changing the receiving programming paradigm.