ORMs map the OOP world to a relational data model

Object-oriented Programming and Relational databases seem as if they were inevitable technologies now that they are almost defacto standards for application development. But each had to prove their versatility in application development and flexibility to adapt to different use cases against some stiff competition.

Early Database systems modeled data hierarchically as a tree of records. These databases forced application developers to think a lot about the internal representation of data in the database.

Relational models solved the problem by hiding implementation details behind a cleaner interface: the SQL. Proposed by Edgar Codd, data in the relational model is organized into relations (called tables), with each relation being an unordered collection of tuples (called rows).

Relational databases also generalized remarkably well across different domains. Popular commercial databases like Oracle and MS SQL grew the RDBMS community and improved the standards and concepts of relational models.

While the database revolution was on its way, Object-oriented programming emerged as a popular choice for simplified application development when people started building bigger and more complicated systems. OOP promised code reuse, made code more readable, and supported loose coupling through abstractions and encapsulation. OOP bought the promise of concepts like encapsulation, inheritance, and polymorphism to the table.

More developers use the OOP pattern today than other programming paradigms like Functional Programming and Imperative Programming. Though OOP is no silver bullet, people consider it a superior option compared to others, primarily because it has a higher chance of reducing bad-quality code.

But for developers constructing Object-oriented applications with an RDBMS as data storage, the two patterns did not gel well in reality. OOP concepts like encapsulation, accessibility, inheritance, and polymorphism are not represented in the RDBMS world. The benefits of strong typing and constraints provided by relational models need to be hand-built in the OOP world.

Object Relational Mappers (ORMs) emerged as a bridge between these two incompatible worlds. An ORM is an awkward translation layer that tries to alleviate the problems with connecting object data models to relational data models.

ORMs like ActiveRecord and Hibernate reduce the amount of boilerplate code but can't hide the models' differences. The data models associated with entities in the real world tend to have a tree structure. In contrast, their representation in the database tends to be flatter and organized in multiple pieces.

The disconnect between the two models is sometimes called Object-Relational Impedance Mismatch derived from the electrical engineering term impedance matching.

The success of ORMs proves that Abstractions are effective means to manage complexity. ORMs do an excellent job of hiding the complexities of interactions between the OOP world and the relational world.

Whether ORMs are good or bad is a matter of debate, though. They are useful in some situations but are oversold on their advantages. It is worth thinking and evaluating ORM libraries carefully before using them.