Re: ORMs comparisons/complaints.
On 1/3/2014 10:38 AM, Chris Uppal wrote:
Given an existing relational database (or set of databases) that:
!) Is/are central to the business (i.e. not there just to "support" some
specific activity).
2) Is a fairly good relational expression of the underlying business model (but
see (3) and (7)).
3) Is old, old, old...
4) Is used by more than one application, which are not all written in the same
language
5) Has severe perfomance problems (caused by the nature of rhe business) even
when accessed via had-written SQL such that there is a fairly large amount of
explicit demnormalisation, and the write-measure-rewrite loop is a central part
of normal, everyday, application development/maintenance. And, even so, many of
the most important processes take long enough to cause very real operational
difficulties for customers.
6) Is not simple, in the sense that most of the "entities" that a user would
think in terms of do not correspond to rows of data in single tables.
7) Has historical quirks (see 3). Such as: no primary keys (the data has
primary keys at the logical level, but -- due to history -- the physical DBMS
itself doesn't know what they are, it just knows about a buch of unique
indexes). No FK constraints (again they are there in the logical model, but
not expressed physically).
Is my feeling that even attempting to use an ORM for developing brand new
applications against the database would be impossible and/or massively
counter-productive, actually defensible ? I.e: am I right to dismiss ORM /out
of hand/ ?
(Incidentally, of the relatively few database I've come across in 30 years of
programming, many fit that pattern).
I don't think you should discard ORM without further investigation.
Nothing of what you mention scream "not possible with ORM".
Specifically I would expect:
* no physical PK to work OK with the ORM when you declared the logical
PK as id in the class
* no physical FK constraints to work OK with the ORM
* write-measure-rewrite to be fine with ORM
* performance of ORM not to be worse than direct SQL
* flexible mapping between classes and table to work OK with the ORM
But based on the general state of the database, then I would say that
the risk of running into a problem is much higher than with a from
scratch database.
And it is given that you can not generate the classes and/or the
mapping automatically from the tables given the description.
And all ORM's are not the same, so some may work better than other
with a scenario as the one described.
[and those types of scenarios are rather common!]
If you have time to research (POC) ORM, then I think you should.
If you do not have time, then you should probably discard ORM
due to the risk of problems due to non-optimal environment.
Arne