ORMs du jour?

[Abigail]

On Mon, Oct 21, 2013 at 04:47:05PM +0100, Dirk Koopman wrote:
> On 21/10/13 15:33, Abigail wrote:
>> On Mon, Oct 21, 2013 at 02:37:52PM +0100, Dirk Koopman wrote:
>>> Any recommendations for an ORM? I am looking for something simple rather
>>> than lots of bells and whistles.
>>
>> My recommendation for ORMs: don't.
>>
>> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
>>
>
> and also
>
> On 21/10/13 15:31, Jason Clifford wrote:> On 2013-10-21 14:37, Dirk  
> Koopman wrote:
> > What is your requirement - ie the use case?
> >
> >
>
> Traditionally what I have done is abstracted all the SQL queries that I  
> want to use into a "class" (read: package) and call those "methods"  
> usually as functions (returning arrays of data). The reason for this is  
> that my programs' SQL queries cover a database's contents very sparsely  
> but specifically and, compared to the size of said database, in a very  
> limited way. An ORM would not have gained me a huge amount of time or  
> enough other "goodness" to make it worth the effort learning that ORM's  
> foibles.
>
> I now find myself needing to provide something that could, in the limit,  
> replicate some C programs that are able create arbitrarily complex  
> "reports", that will be punted into a Mojo webserver for onward service  
> to a punter. The punters in question will not be using SQL :-).
>
> The SQL required will cover a much larger range of the tables (as well  
> as quantities of data) in the database, even for the first cut which  
> will simply webify some existing excel "reports". But the webification  
> only amounts to providing that data in JSON and punting it down a  
> websocket. (Oh and the original screen of course, but that is out of  
> scope for this discussion).
>
> It has to be said that my instinct would be with Abigail. But the very  
> fact that I am asking the question means that I recognise that some  
> OOish view of this database might be useful.
>
> Obviously, if this system that I am starting now ends up where I think  
> it will, I could simply generate SQL queries on the fly and hide them in  
> some real (generated) classes and carry on like that. It is very likely  
> that this, in the first instance, also a reasonable possibility.
>
> The decision could turn either way at the moment.


I see you want an abstraction layer. Abstraction layers can be good [1].
Your code also wants to work with objects. Nothing against that either.
You also seem to have data. But "ORM" stands for three things. You haven't
told us about the relations, nor how you intend to map your objects to
relations.

Quite important is, how are you building it? Do you start with your data,
laid out in tables and relations, and now want an object hierarchy to 
represent this [2]? Or do you have a class hierarchy already, and now you
want a mapping to relations [3]?



[1]  Do note "can". For obvious reasons, abstraction layers tend to be 
     generic. Unfortunally, specially when dealing with large datasets,
     generic can come with a significant cost. Sometimes, code is better
     off bypassing any generic layer, having a specific SQL query that 
     work just then and there, with the current database layout.

[2]  I've yet to see an ORM implementation done this way that doesn't break
     encapsulation and abstraction even before any code is written. As soon
     as you type in "vi NameOfTable.pm", your database layout is dictate your
     code layout, and *poof* goes any abstraction and encapsulation.

[3]  Got a shiny inheritance tree? Perhaps even multiple inheritance? You
     also want a normalized database? Good luck!
    


Abigail