From: arne@vajhoej.dk   
      
   On 7/18/2025 10:44 PM, Lawrence D'Oliveiro wrote:   
   > On Wed, 16 Jul 2025 20:26:46 -0400, Arne Vajhøj wrote:   
   >> You have misunderstood what an ORM provide.   
   >>   
   >> You need to define your object model.   
   >>   
   >> You need to specify logical what queries or updates you want to do.   
   >>   
   >> What the ORM does (as the name implies!) is to handle the mapping   
   >> between the object model and the SQL statements.   
   >   
   > So, if I leave out the ORM, then I don’t need to “define” an “object   
   > model” that it can handle, and just go straight to the queries/updates.   
   > Sounds like less work, to me.   
      
   It is the other way around. If you don't have an object model,   
   then you can't use an ORM.   
      
   But having an object model is normal for larger business applications   
   today. Java, C#, C++, Python, PHP does not matter.   
      
   >> You give it a query and it translate that into one or more SELECT   
   >> statements, read the result and stuff it into the object model.   
   >   
   > I’ve seen ORM calls corresponding to more complex queries, like joins.   
   > Basically you are just expressing the join in a separate language of equal   
   > complexity, with no effort saved that I could see.   
      
   I repeat: the saving is not in the query, but in the mapping from   
   the query result to the object model.   
      
   >> For complex object models having that stuff done automatically save a   
   >> ton of code.   
   >>   
   >> It is cutting 50-75% of the database access code.   
   >   
   > And just replacing it with a lot of ORM code.   
      
   No.   
      
   The mapping code just goes away and is not replaced with   
   anything.   
      
   (well - there is of course code in the ORM framework, but that   
   work is shared among millions of applications)   
      
   >> And most business applications has a lot of database access code.   
   >   
   > I maintain one sizeable application for a client that was written in PHP   
   > (by a previous developer). They tried to wrap table information in custom   
   > classes representing things like employees, work entries, customer   
   > companies and company contacts. The code was just a convoluted mess,   
   > adding complexity instead of removing it. In every page representing some   
   > database query/update function that I needed to make major changes to, I   
   > saved code by getting rid of use of these classes and substituting the   
   > queries and handling the results directly.   
      
   Sounds like you should have chosen an ORM instead!   
      
   :-)   
      
   >> 1) It only makes sense if you have an object model. If your code   
   >>      operate on lists, maps/dictionaries and basic data types, then there   
   >>      is no point in ORM.   
   >   
   > But surely just about all code fits that description.   
      
   It makes sense to keep small applications simple.   
      
   But larger business applications (that are less than 25 years old)   
   almost always use an object model.   
      
   >> 2) There need to be at least one on the team with more than   
   >>      basic skills in the ORM.   
   >   
   > And if you have different apps written in different languages, all   
   > accessing a common database (a very common situation), you need someone   
   > with ORM skills in every language.   
      
   That is a given.   
      
   But it is not a big problem.   
      
   Very few companies have business applications using an object model   
   for operational/transactional use of database in multiple languages.   
      
   Too much code duplication, too many constraints with caching,   
   too much risk for transactional integrity issues.   
      
   Instead they have one application/service own the database and   
   have other applications/services go via that application/service.   
      
   On top of that they may have a number of reporting/analytical   
   and/or data transfer applications in other languages also using   
   the database. But those do not use an object model and therefore   
   have no need for ORM.   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)