From the early days of computing, databases and programming languages went in somewhat different directions as to how they represent and interact with data. Databases ("R"elational stuff) mainly emphasized fast access to large volumes of information on disk, while languages that emphasize manipulation of "o"bjects in a computer's memory had different needs than databases. Thus, databases and traditional programming languages evolved separately, serving different audiences with somewhat different needs.
However, many/most "traditional" applications require database access in some form or another. And so, databases and applications have been joined at the hip more or less as long as they've existed, even though at a low level they remain architected very differently.
The problem is that this disconnect between runtime objects and relational data led to coding difficulties of various kinds. It was just never super reliable or simple for applications to interact with databases. SQL, the most common language for data access and interaction is very different in syntax and execution from other "ordinary" programming languages like C. For one thing, a C compiler for example can't interpret SQL. For this reason, SQL commands have to be run by an application "on faith" so to speak. A compiler can't check a SQL command for errors before it runs, and it doesn't have a way to describe an expectation of results from a database query.
What ORM tries to do is unify relational data and runtime objects so that the complexities, nuances, and hazards of database access are hidden -- and made to look like any other runtime object. When it works, code is easier to write and maintain. It goes haywire when ORM introduces nuances or unexpected behavior of its own. For this reason, based on a range of developer experiences and further wide range of ORM libraries out there, it remains a somewhat polarizing subject in the dev community.
Not sure this explains it "like you're five," but.... this is my best shot. :-)
From the early days of computing, databases and programming languages went in somewhat different directions as to how they represent and interact with data. Databases ("R"elational stuff) mainly emphasized fast access to large volumes of information on disk, while languages that emphasize manipulation of "o"bjects in a computer's memory had different needs than databases. Thus, databases and traditional programming languages evolved separately, serving different audiences with somewhat different needs.
However, many/most "traditional" applications require database access in some form or another. And so, databases and applications have been joined at the hip more or less as long as they've existed, even though at a low level they remain architected very differently.
The problem is that this disconnect between runtime objects and relational data led to coding difficulties of various kinds. It was just never super reliable or simple for applications to interact with databases. SQL, the most common language for data access and interaction is very different in syntax and execution from other "ordinary" programming languages like C. For one thing, a C compiler for example can't interpret SQL. For this reason, SQL commands have to be run by an application "on faith" so to speak. A compiler can't check a SQL command for errors before it runs, and it doesn't have a way to describe an expectation of results from a database query.
What ORM tries to do is unify relational data and runtime objects so that the complexities, nuances, and hazards of database access are hidden -- and made to look like any other runtime object. When it works, code is easier to write and maintain. It goes haywire when ORM introduces nuances or unexpected behavior of its own. For this reason, based on a range of developer experiences and further wide range of ORM libraries out there, it remains a somewhat polarizing subject in the dev community.
Not sure this explains it "like you're five," but.... this is my best shot. :-)
It is not for a 5 year old, but it is a nice explanation. I appreciate that you took the time. :-)