Ask HN: I don't understand what problems ORMs solve

3 pointsby iondodonanno scorso7 comments

I don't understand what problems ORMs solve. Can you please help me understand? Why do they exist?

8 comments

gjvcanno scorso

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.

iondodonanno scorso

Are they better than writing raw SQL?

elrosanno scorso

In software engineering there's rarely an objective way to answer "better" or "worse", it's more often a question of trade-offs.

An ORM is the choice to trade some performance and a little complexity in exchange for some convenience.

This is of course a simplification, there are other aspects to be considered.

Personally, it seems to me that this is a trade-off which is often valuable.

That being said, it's not necessarily the case that by using an ORM you are not using SQL. There are ORMs that offer you a way to abstract away SQL, others take a mixed approach where you use SQL to define structure and migrations, but use the ORM to manipulate data, for example.

What's more, each ORM has a slightly different set of features, depending on what their authors thought would be better. There's no universal "correct" way to build an ORM.

In some situations the loss of control you get when using an ORM is not worth it, because one could write better queries by hand. In other situations it might lend itself. Also different people will have different experiences and a different skillset, which also leads to different decisions.

It's all about what makes your life easier in terms of building maintainable software in the specific situation you find yourself in.

gjvcanno scorso

see also https://blog.codinghorror.com/object-relational-mapping-is-t...

which is commentary on the original source:

https://web.archive.org/web/20220823105749/http://blogs.tedn...

elrosanno scorso

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

radonekanno scorso

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.

iondodonanno scorso

Thank you everyone!

[deleted]anno scorso