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: https://stackoverflow.com/questions/404083/is-orm-still-the-vietnam-of-computer-science

  • 1
    could you elaborate a bit more about what you mean by "non-technical" factors? Oct 9, 2010 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, 2010 at 23:15
  • Does this answer your question? Is ORM an Anti-Pattern?
    – gnat
    Aug 1, 2020 at 12:19

3 Answers 3


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?

  • 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, 2010 at 10:36
  • 2
    @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. Oct 13, 2010 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, 2014 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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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