Active Record: How We Got Persistence Perfectly Wrong (2023) (opens in new tab)

My impression is otherwise.

The worst trouble with the "impedance mismatch" is that there are three ways to create database tables to represent inheritance relations and they are all terrible. He doesn't talk about that at all. Most versions of "Active Record" don't make a serious attempt to establish the OO world inside the relational world and I see them as, fundamentally, an improvement over junior programmers writing

   db.execute("INSERT (x,y) INTO z VALUES ("+x+","+y+")")

although a really simple library like

   t = db.table("z")    # pure sugar, doesn't even look up "z" in the schema!
   t.insert({"x":x, "y": y})

solves that problem pretty well, particularly in the context of modern SQL-in-X DSLs like JooQ and SQLAlchemy where you can write something like

   t.update(
      {"y": lambda z: z["y"] + 1},            # set clause 
      {"x": lambda z: z["x"] % 2 == 0 }       # where clause
   )

His attitude that OO > relational can be turned around: for instance, migrating a database that has 10,000,000 user records in it is going to a be a serious affair no matter how you do it and you could say it is trivialized by your ability to change the data type you use in a class definition check it into version control and then

   git checkout X

to whatever version you want without doing the difficult physical transformation of the data tables. OO has a strong tendency to set things up in a definite hierarchy, in the case of a user management system, for instance, users are typically organized into "groups". Do you write

   group.addUser(u1)

or

   user.addGroup(g1)

? The author would probably reject this but I'd base the requirements in "what does the user interface look like?" and I would come to the computer that the administrator of the system might be looking at the screen for a user and want to add that user to a group or be looking at the group screen and add a user. The rookie "product" manager will usually decide we need one, but it's predictable [1] that the administrator will think otherwise and insist on the other.

The author does not discuss any better way of handling persistence because it doesn't really exist -- sure the messy "document database" solves the inheritance problem (which he doesn't talk about... if he did we'd get into the question of "is inheritance toxic?") Attempts to make native OO databases where you persist all your Java objects are a notorious dead end.

[1] like the contact info form which has two email addresses and will inevitably need N