the clue's in the name. Some people thought you could map the fields of objects to the fields of a relation (aka columns in a table) in a database. This approach has had mixed success.

When storing data, particularly when stored in a relational model, it's quite often better to make sure the data is properly normalized[0]. However, normalized data in the way that suits the data model might not be the more convenient way to operate on it from the perspective of your domain logic.

Additionally, the data types in your data model are limited by what your data layer supports, but on the domain side you might want to have richer data types.

ORMs make it easier to obtain the data in a shape and in types that are useful to you from a domain model perspective, while still storing the data in a way that's useful for the database side of things.

Example 1:

I want to store Users which have a `name` and `date_of_birth` property in a table. However, when operating on that object in the domain side, I might want to have instances of a User class which might expose a method such as `isOfLegalAge()`, which would let me know whether that user is old enough to, let's say, sign a mortgage contract.

A ORM makes it easier for me to get back an instance of a User class (which can have useful methods), instead of having to operate on a database row structure, which would give me strictly data.

Example 2:

A given Product, which has a `name` and a `price`, might be supplied by a Supplier, which has a `name` and an `location`. When fetching a user from a database, I might want to have an object in a shape such as:

  Product {
     name: string
     price: number
     supplier: {
        name: string
        location: {
           city: string
           country: string
        }
     }
  }

However when I store it, a Product would have a reference to a `supplier_id`, which points to a row in the Supplier table. The supplier's location's city and country would be a city_id and country_id, each of which referencing a row in a City table and a Country table.

So from a data model representation it might look more like this:

  Product {
     id: number
     name: string
     supplier_id: number
  }

  Supplier {
     id: number
     name: string
     location_id: number
  }

  Location {
     id: number
     city_id: number
     country_id: number
  }

  City {
     id: number
     name: string
  }

  Country {
     id: number
     name: string
  }

The ORM would map between these two representations.

[0] https://en.wikipedia.org/wiki/Database_normalization

ORM is not as much solution to a problem as it is way of doing things. Certain kind of programmers observe that SELECT is kinda like getter, UPDATE is like setter and so on… It looks like cool abstraction, relatively straightforward to implement and most people working with databases toy with their own ORM code, have fun and thinks themselves very clever. Think of it as a rite of passage if you will.

…until they try to do JOIN. Or subselect. Or CTE. Or just about any other powerful SQL feature. Materialized views, triggers, sharding, atomic operations, you name it. At which point ones who are actually clever realize this idea has some serious limitations and drop it. Not because it can't be done – there are some nifty and well working ORMS out there – but because its bound to end just as complicated as sql itself. So why bother?

IMO main reason for existence of the ORM libraries is because back in the day, true object databases failed to take off for various reasons.

Thank you everyone!