Can you represent the application object the way a relational database can understand?

Bill Karwin has a blog post titled Why Should You Use an ORM ? Which is discussed on Reddit and I was confused about several points.

In it, he says in the comment section:

OODBMS and ORM only work with objects that we have created in the application layer. That is, there is no way to make a request like this:

UPDATE Bugs SET status = 'CLOSED' WHERE status = 'OPEN';

To do this in an ORM or OODBMS, you will need to get all errors that match the criteria and create objects for them. Then you can set the attribute and save the objects back to the database one by one. This is costly and certainly requires more code than the equivalent SQL shown above.

This illustrates the advantage of a SQL-like language that treats sets as a first-class data type. The OO paradigm cannot replace the relational paradigm in all cases. There are some common operations that SQL can do much better.

I have highlighted the part where it says you need to create objects for these errors when you are using the ORM, because that is the part I am confused about.

My question is, why should you? Okay, object oriented is one thing and relational is another. But is it really so that they are so different that there is no way to represent an object so that it can be understood by a relational database? For example, I am thinking about how you can serialize an object and then write to a file storage format. Could you use a format like this to transfer an object to a relational database?

+2


source to share


3 answers


is there no way to represent an object so that it can be understood by a relational database?

You missed my comments. I didn't mean that you can't store an object in a relational database. I meant that the OO paradigm assumes that you have an instance of this object in the application space. That is, you can call methods and accessor properties on an object:

$bug->status = 'CLOSED';
$bug->save();

      

But in any ORM I've seen * you cannot work with an object instance without fetching it from the database. You can also work on entire sets of rows at the same time, as you can with SQL.

It would be interesting to see ORM package that had a comparison of the types of objects in a set of data. Then, when you change the attribute, it is applied to all rows in that set. I have not seen ORM attempts to do this.



It would be very difficult due to concurrency issues. Does the set include the rows that were in that set when you instantiated the object, or when you make a change, or when you save your changes? If it supports all of these permutations as parameters, then it starts to get so complex to use that it can rightfully be assumed that it does not represent an actual improvement over using SQL directly.

Repeat your comment: It's not that sets and objects are incompatible. A collection can be an object (Java even has classes for Collection and Set). But the OO paradigm assumes that operations are applied to a single instance of an object, whereas relational operators are always applied to sets (a single row set is still a set). And in fact, the ORM packages that exist today make the same assumption that only one instance of a row can be changed at a time, and you had to retrieve that row before you could change it.

It is possible in theory to extend the ORM's capabilities to work on sets, but AFAIK nobody tried to do that. My contention is that an ORM that could do everything that relational operators can do would be much worse than SQL.

* I exclude pseudo-languages โ€‹โ€‹like SQL like HQL that are part of an ORM package (Hibernate in the case of HQL), but the pseudo-language itself does not qualify as an ORM.

+3


source


ORM maps the state of objects to the equivalent state in the database. Thus, if you want to change the state of something in the database using an ORM, the only mechanism you have for you is to first manipulate the objects represented by the database and then save their state.

I'm not sure what you mean:



I am thinking about how you can serialize an object and then it is written in a file storage format. Could you use a format like this to pass a relational database object?

Do you mean serializing an object into a structure that you could store mostly in a flat file (like XML) and then store that data in a database? If yes, then yes. The challenge will be that you want to find this information. Let's say you wanted to find all the "closed" errors, you would need to read each error, deserialize it, and check its status to see if it should be listed.

+1


source


The main purpose of ORM is to transform data from one view to another; the tone of your quote is that SQL is better suited to batch work, which is true - since the ORM converts relational data tables to object graphs and then back to tables.

A (very loose) analogy has a vat of pulp that you want to dye red. If the wat represents a SQL database, you just dump the paint and serve it up. Using an ORM would be like converting pulp to paper, shredding individual sheets, and then re-boiling the (now colored) paper to return to the vat.

+1


source







All Articles