Making the Leap from RDBMS to Persistent Objects
gemstonesoup.wordpress.com
Making the Leap from RDBMS to Persistent Objects
1–3 of 3 posts
Re: Making the Leap from RDBMS to Persistent Objects
#2I have disagree with some of this article.
If your app needs to treat an attribute of an object (user_name in this example) as unique within the set of objects of its "type" (User), you put the constraint somewhere it is manageable and DRY. This true without regard to if the persistence is RDB or ODB.
In something like Rails, the constraint gets handled in ruby. You also have the choice, in Rails and such, of additionally having the constraint in your RDB schema.
Gemstone is a unique ODB in that code gets executed in process with the data. This is not so with other ODBs which are only a repository and most operations on objects occur outside the repository.
Gemstone is very cool and you can do lots of things much faster and smarter with it. But OO practice of encapsulating the behavior of changing the user_name is the same without regard to the use of Gemstone, some less glorious ODB, or an RDB.
Re: Making the Leap from RDBMS to Persistent Objects
#3I have disagree with some of this article. If your app needs to treat an attribute of an object (user_name in this example) as unique within the set of objects of its "type" (User), you put the constraint somewhere it is manageable and DRY. This true without regard to if the persistence is RDB or ODB. In something like Rails, the constraint gets handled in ruby. You also have the choice, in Rails and such, of additio…
You have a good point that user_name validation is the same whether or not you use a DB or not, however, if you have been leveraging an RDB for doing validation, queries and collection management, then making the transition to doing all of your work in objects (i.e., using an ODB), means that you need to start thinking in terms of objects everywhere.
This turns out to be a fairly common question from folks transitioning from RDBs