4 ms·

Not to get too off topic, but ORMs are bags of design flaws. They are definitional technical debt, the kind that gets you from proof of concept but needs to be

• 9rx 1y ago
  In realistic practice there is no escaping it, though. Even if you maintain relations throughout the majority of your application, you are almost certainly still going to need to call some kind of third-party API or networked service that requires mapping between relations and objects. Especially if networked services are involved as they nearly always eschew relations in favour of objects to avoid the typical n+1 problems. Should your application map objects and relations at all isn't usually a question you get to ask unless it is doesn't do much or lives on its own private island. Should you do it yourself or lean on a toolkit to help is the question that you have to contend with.
  • seadan83 1y ago
    A DB query without ORM is effectively a service. This hides relations in the DB layer, rendering moot the need to model these relations in object oriented code. Thus, eschewing the ORM completely moots the question of whether to map objects and relations. I'd suggest if you are ever asking that question, you are already screwed.
    • 9rx 1y ago
      Querying and ORM are very different concepts. Object-relation mapping is concerned with, as it literally asserts, mapping between relations (or, more likely in practice, tables – but they are similar enough for the sake of this discussion) and objects. Maybe you are confusing ORM with the active record pattern (popularized by ActiveRecord, the library) which combines query building and ORM into some kind of unified concept? ActiveRecord, the library, confusingly called itself ORM when it was released which may be the source of that.
      • skydhash 1y ago
        Was confused by that too (ORM and Active Records), but I spend some time learning about DDD which leads me into enterprise architecture and that's when I all the design pattern for interacting with data. Most web frameworks only have Query Builder and Active Records.
      • seadan83 1y ago
        First, for definitions, I'd suggest we use wikipedia for ORM [1] and also Active Record Pattern [2]. I believe Active Record is a more specific implementation of something that is ORM-like. We can stop speaking of Active Record since my point holds for the more generic ORM, and therefore holds for Active Record as well. To clarify my point, there is a fundamental impedance mismatch between object mapping of data vs relational database mapping of data. One implication of this is you cannot use database as a service. Interactions with database must instead be gated behind the ORM and the ORM controls the database interaction. I'll note that database as a service is very powerful. For example, when there is an API contract exposing a value that is powered by some raw-dog SQL, when the database changes, anything using the API does not need to change. Only the SQL changes. In contrast, when an ORM exposes an object, an attribute might sometimes be loaded, sometimes not. A change to load or not load that attribute ripples through everything that uses that object. That type of change in ORM-land is the stuff of either N+1 problems, or Null-Pointers. To back up a bit, let me re-iterate a bit about the impedance mismatch. Wikipedia speaks of this [1]: "By contrast, relational databases, such as SQL, group scalars into tuples, which are then enumerated in tables. Tuples and objects have some general similarity... They have many differences, though" To drive the point home - in other words, you can't do everything in object world that you can do in a database 1:1. A consequence of this is that the ORM requires the application to view the database as a persistence store (AKA: data-store, AKA: object store, AKA: persistence layer). The ORM controls the interaction with database, you can't just use database as a data service. I believe this point is illustrated most easily from queries. To illustrate, let's pull some query code [3] from Java's Hibernate, a prototypical ORM. ``` public Movie getMovie(Long movieId) { EntityManager em = getEntityManager(); Movie movie = em.find(Movie.class, new Long(movieId)); em.detach(movie); return movie; } ``` So, getting a release year might look like this: ``` int movieId = 123; Movie m = orm.getMovie(movieId); return m.getReleaseYear(); ``` In contrast, if we put some raw-dogged SQL behind a method, we get this code: ``` int movieId = 123; return movieDao.getMovieReleaseYearByMovieId(movieId); ``` Now, let's illustrate. To do this, let us look at the example of finding the release year of the highest grossing movie. As a service, that looks like this: ``` return dao.findReleaseYearOfHighestGrossingMovie(); ``` In contrast, as an ORM, you might have to load all Movies and then iterate. Maybe the ORM might have some magic sugar to get a 'min/max' value though. We can go on though, let's say we want to get the directors of the top 10 grossing movies. An ORM will almost certainly require you to load all movies and then iterate, or start creating some objects specifically to represent that data. In all cases, an ORM presents the contract is an an object rather than as an API call (AKA, a service). For the update case, ORMs often do pretty well. ORMs can get into trouble with the impedance mismatch when doing things like trying to update joined entities. For example, "update all actors in movie X". Further, ORM (and objects) creates issues of stale/warm caches, nullity, mutability, performance, and more... What is worse, all of this is intrinsic, relational data and objects are intrinsically different. [1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapp... [2] https://en.wikipedia.org/wiki/Active_record_pattern https://en.wikipedia.org/wiki/Active_record_pattern [3] https://www.baeldung.com/hibernate-entitymanager https://www.baeldung.com/hibernate-entitymanager
  • awkward 1y ago
    Oh for sure, they fill huge and consistent gap between most databases and most programming languages. The issue is that they are fundamentally a compromise. That means it's not damning to hear that issues crept in with scale and complexity. It's also rarely practical to take on the project of making a slightly different set of compromises from first principles.
    • 9rx 1y ago
      > The issue is that they are fundamentally a compromise. Which is no doubt why most newer applications I see these days have trended towards carrying relations as far as they can go, only mapping with objects at the points where it is absolutely necessary. > It's also rarely practical to take on the project of making a slightly different set of compromise I suppose that is the other benefit of delaying mapping until necessary. What needs to be mapped will be more limited in scope and can be identified as such. You don't have to build a huge framework that can handle all conceivable cases. You can reduce it to only what you need, which is usually not going to be much, and can determine what tradeoffs best suit in that. In this type of situation it is likely that using a ORM library is going to be a bigger waste of time, honestly.
• bob1029 1y ago
  > There are a large number of fundamental impedance mismatches between relational data and object based data My experience tells me that the largest among these impedance mismatches is the inability for OOP languages to express circular dependencies without resorting to messy hackarounds. Developers often fail to realize how far they are into the dragon's den until they need to start serializing their object graphs. https://github.com/dotnet/runtime/issues/29900 https://github.com/dotnet/runtime/issues/29900