[Haskell-cafe] Usefulness of abstracting data storage, WAS: A universal data store interface
amindfv at gmail.com
Mon Feb 13 21:43:31 CET 2012
Mailing list thread split!
The GSoC seems like it should have its own list thread, so I'm moving
this other discussion:
On 2/13/12, Paul R <paul.r.ml at gmail.com> wrote:
>> The most proeminent example is probably PostgreSQL, which is an
>> incredibly strong product with high SQL power. But as soon as you access
>> it through the ActiveRecord or Persistent API, it gets turned into
>> a very limited store, with the SQL power of SQLITE or MongoDB.
> Tom> "Limited" /= "Worst", though .
> Tom> The popularity of SQLite and "NoSQL" prove that sometimes a limited
> Tom> feature set is worth the gains in abstraction.
> Tom> Definitely not for every project, of course.
> I don't dismiss MongoDB nor SQLite, they are great. But you probably
> don't want to limit MongoDB to a SQL features set, and you don't want to
> limit SQLite to a "NoSQL" interface, and you don't want to limit
> PostgreSQL to a SQLite features set ...
> As you said, each of these stores has strenghs for particular needs and
> weaknesses for others. Pick the one that best suits your project, and
> use its full power, raw :)
I agree about strengths and weaknesses of different data stores.
However for my uses, I prefer Haskell Functors to any particular data
store. The tool that helps me stay within Haskell the most is the one
which I'll choose.
More information about the Haskell-Cafe