Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^6: Maybe database tables aren't such great "objects," after all ...

by DStaal (Chaplain)
on Mar 28, 2011 at 19:11 UTC ( [id://896001] : note . print w/replies, xml ) Need Help??

in reply to Re^5: Maybe database tables aren't such great "objects," after all ...
in thread Maybe database tables aren't such great "objects," after all ...

It still seems to me that sometimes you'd want to operate on a number of objects inside a single transaction and other times in different transactions.

Yes you will. And sometimes that will mean you change a single record in a single table, and sometimes that will mean you'll change a dozen records in a dozen tables. My statement and yours do not map to each other.

Stop thinking of data in the database as 'objects'. It's not. It's data. It knows nothing about what code should operate on it. Organize it based on it being data, in the best form to store and retrieve it.

And code your objects to get their data (possibly through some database API of some sort) from the data store and use it in the most effective way for the program. Write the API to handle transferring it in a way that's not visible to the (object) programmer.

Then maybe you'll stop getting hung up on the idea that you are storing your objects in a database.

Will there be limits? All this is abstraction. Eventually the data is being stored as a series of bits. Eventually the program is being run as imperative assembly code. Stress the abstractions hard enough, you'll run into places where they can't hide what they are abstracting. That's the nature of abstractions. But don't start confusing one layer of abstraction in one domain with a different layer of abstraction in a different domain just because they are both abstractions.

  • Comment on Re^6: Maybe database tables aren't such great "objects," after all ...