4

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

Community
  • 1
plaureano
  • 1,231
  • 1
  • 11
  • 13
  • 1
    could you elaborate a bit more about what you mean by "non-technical" factors? – Ryszard Szopa Oct 09 '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
  • Does this answer your question? [Is ORM an Anti-Pattern?](https://softwareengineering.stackexchange.com/questions/120321/is-orm-an-anti-pattern) – gnat Aug 01 '20 at 12:19

3 Answers3

6

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?

Craig
  • 4,302
  • 3
  • 21
  • 21
  • 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 08 '10 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. – 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
0

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.

luis.espinal
  • 2,560
  • 1
  • 20
  • 17
0

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.

Michael Brown
  • 21,684
  • 3
  • 46
  • 83