From ed4aadca62c352b236ebc3401a6c5228a702f31d Mon Sep 17 00:00:00 2001 From: Gavin King Date: Fri, 21 Nov 2025 13:26:56 +0100 Subject: [PATCH] add a new definition of what ORM is all about --- .../src/main/asciidoc/introduction/Introduction.adoc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/documentation/src/main/asciidoc/introduction/Introduction.adoc b/documentation/src/main/asciidoc/introduction/Introduction.adoc index e346531b2939..968b1f3e33e0 100644 --- a/documentation/src/main/asciidoc/introduction/Introduction.adoc +++ b/documentation/src/main/asciidoc/introduction/Introduction.adoc @@ -23,6 +23,14 @@ The goal of _object/relational mapping_ (ORM) is to eliminate fragile and untype ORM takes the pain out of persistence by relieving the developer of the need to hand-write tedious, repetitive, and fragile code for flattening graphs of objects to database tables and rebuilding graphs of objects from flat SQL query result sets. Even better, ORM makes it much easier to tune performance later, after the basic persistence logic has already been written. +Actually, the problem that object/relational mapping solves has been mischaracterized for decades, and has very little to do with any so-called "mismatch" between classes and tables. The real problem is: + +1. Data is stored in **normalized tables**. +2. The process of efficiently reading data from tables **<>**. +3. In an object-oriented program, we often want to work with data in something quite close to its **original normalized form**. + +Therefore, the principal task of object/relational mapping is to _renormalize the data after reading it from the database_. This need exists even if the classes in our program are identical to the database tables. + [TIP] // .ORM or SQL? ====