Re: [Caml-list] Long-term storage of values

[Dario Teixeira <darioteixeira@yahoo.com>]

Hi,

> You're making two mistakes.
> 
> Mistake #1: treating a database as a dumb object store.  This is a really 
> popular idea right now- Hibernate does this, as does Ruby on Rails, and a 
> number of other ORM packages take this effective approach.  On the other 
> hand, dynamically typed languages are also really popular.

Thanks for your reply.  It was quite interesting, though I get the feeling
you used my question solely as a trigger to share with us a long-held
dissatisfaction with the current state of affairs concerning the use of
databases, regardless of whether it actually applies to my particular problem.
That's fair, and I do agree with practically all your points.  However,
if I were you I would refrain from starting such missives with statements
as blunt and uncompromising as "You're making two mistakes".  As it turns
out, this is one of those cases where the data (tree-like, with recursive
structures) does not map well at all with a relational database.

Moreover, I am far from treating the database as a dumb object storage.
In fact, a significant portion of the code for this particular application
(a web app using Ocsigen; you can download a preliminary version of the app
from http://dario.dse.nl/projects/lambdium-light/) lies on the Postgresql side,
with the Ocaml code serving as little more than delivery boy.  The exception
is of course those portions where it is far more natural and performant to let
the Ocaml code take the reins and treat the DB as dumb storage.  The complex
data structure holding the markup of stories/comments is one such example.


> So, mistake number one: either use the data, and structure your data (at 
> that layer) to take advantage of it, or don't use a database.

Unfortunately, this is an overly general statement.  I have no doubt that
if I were to present you the data I have, your reply would be "in this case,
just use the DB as dumb storage".


> Mistake number two: file formats (and this includes marshalled data 
> structures), are wire protocols, and need to be designed to be as abstract 
> as possible- to reveal as little about the internal structure of the 
> program as possible (preferrably none at all).

On the other hand, one of the advantages of using a language with such a
rich type-system as Ocaml's, is that the application-independent description
of the data can be translated on practically a 1:1 basis to native language
constructs!  Trust me, I didn't need to bend the data definition to suit
the internal structure of the programme.

Kind regards,
Dario Teixeira



      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/