Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know the technical pitfalls of writing an ORM are pretty well-known nowadays, but what are some non-technical factors (e.g., Scope) that make it difficult to writing a good ORM?

I have already read the technical reasons for why ORMs are so difficult to write from this Stackoverflow post:

share|improve this question
could you elaborate a bit more about what you mean by "non-technical" factors? – Ryszard Szopa Oct 9 '10 at 17:07
Some examples of non-technical factors include time, and scope. We all know about the object-relational impedance mismatch and the difficulties that it causes, but I'm more interested in finding out if there are some other non-technical reasons why it's so difficult to write an ORM. – plaureano Oct 10 '10 at 23:15
up vote 5 down vote accepted

I think the Object relational impedance mismatch is the big problem. OO is not relational. For example, where does relational theory describe inheritance. Also smaller (but big issues) like if the programming language doesn't support nullable types. How do you map that to a nullable column in the database?

share|improve this answer
If a null value comes from the UI, a web service or a relational database's nullable column, don't you have to handle it? – JeffO Oct 8 '10 at 10:36
@Jeff O - how you handle it depends on your specific requirements. There is no universally applicable rule that we can apply when facing a null. In some cases, the correct way to handle it is by throwing a NPE. In other cases, an implicit conversion of sorts is required. In other words, you handle it according to your requirements. – luis.espinal Oct 13 '10 at 16:55
For example, where does relational theory describe inheritance. - Dunno about theory, but in practice: the "child" table could have a primary key that is also a foreign key to the "parent" table. – Izkata Feb 22 '14 at 17:28

Time and scope are technical factors as they are orthogonal to time/space resources and output reach (scope) used by a particular process (in this case, writing a piece of software.)

A non-technical reason would be driving out requirements, requirement elicitation, customer negotiation and so on. It would be hard to measure the effect of such non-technical reasons (or impediments) to the development of something that is clearly meant for usage by technical staff.

share|improve this answer

The biggest obstacle to creating a good O/RM is trying build an O/RM. Create the simplest solution that solves the problem at hand. Then as you identify problems that your solution doesn't address, expand. If you set out to create an O/RM the sheer scope of that problem will keep you from getting even a simple solution working.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.