4 ms·

The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. Unless your entire application is mo

The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. Unless your entire application is modelled as relations, there is no avoiding this transformation step, be it whether you use a toolkit to help you or slog it by hand. SQL doesn't help you here. SQL is just a query language that is designed around the relational model (more or less). The same relational model that your application isn't (likely) designed around. Thus, again, you need object relation mapping to provide the conversion between SQL's model and your application's model. Some ORM toolkits also bundle query builders. The query builder may be what you find unnecessary, but I'm not sure the existence of query builders is crazy. These query builders essentially become another programming language that compiles to SQL. The idea of a programming language compiling to another programming language isn't crazy at all. We do it all the time with great success. Although there is debate as to whether or not it is due to SQL/RDBMSes not being purely relational or if it is more fundamental, what is agreed upon is that there is an object relation impedance mismatch. This makes it a hard problem to solve and many ORM toolkits only provide half solutions, and this is where a lot of friction comes into play.

fckgnad 4y ago
>The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations. You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual. Here's another way to put it: The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.
- randomdata 4y ago
  > It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. I'm not sure object oriented programming ever really caught on. The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". > SQL is already a high level abstraction. SQL is a high level query abstraction, but we're talking about the data model. Again, a relation is nothing more than a set of tuples[1]. That is a very primitive data abstraction. Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? > The models already exist in the database. Why build a repetitive model in the application language? Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. > It's a cosmetic thing because people don't want to deal with string manipulation. String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. [1] If we are being pedantic, SQL actually deviates from the relational model by not staying completely true to sets. But the terminology has stuck regardless.
  - acdha 4y ago
    > The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". What about Java, C#, and Python? The first two have been go-to at many businesses since the turn of the century. If C++ isn’t mainstream it’s because in no small part people picked those instead.

fckgnad 4y ago

>The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as. I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations. You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual. Here's another way to put it: The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.

randomdata 4y ago
> It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go. I'm not sure object oriented programming ever really caught on. The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". > SQL is already a high level abstraction. SQL is a high level query abstraction, but we're talking about the data model. Again, a relation is nothing more than a set of tuples[1]. That is a very primitive data abstraction. Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? > The models already exist in the database. Why build a repetitive model in the application language? Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. > It's a cosmetic thing because people don't want to deal with string manipulation. String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. [1] If we are being pedantic, SQL actually deviates from the relational model by not staying completely true to sets. But the terminology has stuck regardless.
- acdha 4y ago
  > The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go". What about Java, C#, and Python? The first two have been go-to at many businesses since the turn of the century. If C++ isn’t mainstream it’s because in no small part people picked those instead.