Explain ORM like I'm five

Nested data structures are a pain to load and save to the database. That’s the primary reason ORMs exist. They auto generate code objects based on the tables or vice versa and handle saving nested objects in one transaction. I hate ORMs but I am a fan of “micro ORMs” like Dapper, which just maps rows to objects.

Instead of using an ORM for nested objects, I store the object as a JSON document. Postgres has a lot of good functionality around these.

I'm the database. I have data organized into related tables: there is a stables table with addresses, capacity, and so forth; a horses table containing names and vitals and a link to the stable quartering the horse; a riders table containing other names and other vitals; and a horse_riders table linking individual riders to individual horses, since a rider may switch out or share horses. There's also a statistics table with event names, times, and awards for a given horse; each record is a separate event.

You're an application which displays horse data and allows users to edit and create more horse data. You need to talk to me in order to make that happen.

There are a few ways of accomplishing this. Object-relational mapping is one of the more common approaches but is by no means unambiguously the best (it's been called "the Vietnam [War] of computer science") and I tend to agree with that characterization).

With an object-relational mapper, you think about how you want to work with horse data and create a set of models which loosely correspond to my schema. You might combine the horses and statistics tables into your Horse model, for example, and will likely not even consider the horse_riders junction table at all -- the O/RM abstracts that part away for you. Your Stable object even has its own collection of Horses attached, which can be eagerly or lazily loaded with little to no effort on your part! This loose correspondence is what we call the object-relational impedance mismatch: a Horse with its own statistics may be easier to work with in the application context, but it's different from how the data are actually represented. This saves time in the short term but makes adaptation much more difficult. When (it is not a question of "if") you need to do something you didn't originally account for, you will wind up doing one of two things:

• major surgery on your data model
• writing SQL, the thing the O/RM was supposed to do for you

This is not to say that object-relational mapping is without advantages. It makes the first 90% of data access pretty straightforward, especially if you're using an object-oriented language. And it tends to use lowest-common-denominator functionality of the database, if supporting multiple engines is a pressing concern. But I don't feel that those advantages outweigh the inevitable drawbacks, especially when there are alternatives like the data mapper pattern.

You want to talk to someone.

You don't speak their language.

You ask someone to translate for you.

Something gets translated wrong.

You are now angry.

(SCNR)

Imagine you have a box that automatically order all your building blocks in whatever way you want to.
Your building blocks are data entries in the database.
The magic box is the ORM which allow you to make a better use of your building blocks.
Let's say you are creating a boat, so you need round pieces for the life boats. You ask to box for only round pieces.
In development this is called a query and a ORM help you to query in the DB
Let's assume you buy more building blocks. You put them in the magic box and everything is order.
An ORM will help you to add data to the database taking care of inner capabilities of the DB. By examples if the tables exist or not. If the magic box knows the type of building block or it is the first time it see it.
Now imagine you used to buy Legos, and found a compatible alternative brand, so you buy thoose and put them in your magic box.
An ORM also take cares of creating databases.
Now imagine your father or mother bought a bunch of building blocks as a surprise gift for your birthday, the box will take care of not letting you know those are there untill your parents decide to allow it. An ORM handle users and permissions in an easy way.

Gents during the 90's where complaining about how error prone was retrieving data from relational databases for use with applications, so some other gents came up with a way of (M)apping the (R)elational models of rdbms to (O)bjects in their applications (by referring to db rows as objects and table columns as attributes) as means of addressing said issues thus giving birth to the ORM approach to application data management.

From the early days of computing, databases and programming languages went in somewhat different directions as to how they represent and interact with data. Databases ("R"elational stuff) mainly emphasized fast access to large volumes of information on disk, while languages that emphasize manipulation of "o"bjects in a computer's memory had different needs than databases. Thus, databases and traditional programming languages evolved separately, serving different audiences with somewhat different needs.

However, many/most "traditional" applications require database access in some form or another. And so, databases and applications have been joined at the hip more or less as long as they've existed, even though at a low level they remain architected very differently.

The problem is that this disconnect between runtime objects and relational data led to coding difficulties of various kinds. It was just never super reliable or simple for applications to interact with databases. SQL, the most common language for data access and interaction is very different in syntax and execution from other "ordinary" programming languages like C. For one thing, a C compiler for example can't interpret SQL. For this reason, SQL commands have to be run by an application "on faith" so to speak. A compiler can't check a SQL command for errors before it runs, and it doesn't have a way to describe an expectation of results from a database query.

What ORM tries to do is unify relational data and runtime objects so that the complexities, nuances, and hazards of database access are hidden -- and made to look like any other runtime object. When it works, code is easier to write and maintain. It goes haywire when ORM introduces nuances or unexpected behavior of its own. For this reason, based on a range of developer experiences and further wide range of ORM libraries out there, it remains a somewhat polarizing subject in the dev community.

Not sure this explains it "like you're five," but.... this is my best shot. :-)

You are in a Chinese restaurant and you don't speak Chinese. You were given the menu with Chinese texts that you don't understand. In order for you to to order, you need to study Chinese and tell the waiter what you want by speaking in Chinese. That's fine if you are not hungry enough and you have time to study the language before you can eat.

Now every customer who doesn't understand the language have to study it before they can eat. The line outside the restaurant became very long. And that's not good for the business. So the owner decided to create a new menu where he matched every menu item with a picture and a number so that when you order from the waiter, you either just point to the picture or tell the number. That makes it easier for you tell what you want to eat.

I am a translator that will talk to any database you could want.

So glad you asked this Q!