From: Christopher Dicely Date: 2009-08-14T00:08:19+09:00 Subject: Re: Destroying related objects doubt ... basic oop question On Thu, Aug 13, 2009 at 7:26 AM, Mike Stephens wrote: > Christopher Dicely wrote: >>  the  data is still being controlled by the Ruby program. > > That would mean anyone across the entire corporation is somehow going to > have to call your classes to manipulate the data. No, it wouldn't. Whether you use an ORM or not, anything that can access the backing database can manipulate the data, and using an ORM -- even using its calls to handle things like associations -- doesn't make the database inaccessible to other users. Now, if you solely use application-level code to specify what are logically constraints that apply to the data rather than the particular use in your application, then, yes, your database is not going to be set up in the best manner for other users. And yes, certain opinionated ORMs (ActiveRecord used to be this way, though I gather it has improved some) may work more easily with setups that are less than ideal for other users. That's not a fundamental problem with ORM, so much as a reflection of the particular use-cases that shaped the development of those particular ORM libraries. > If you're Warner Brothers and you want to work out what DVDs you've sold > today in the South American Regions you aren't going to use Ruby. It's > going to be Oracle and related special products, and that's what it's > like everywhere. Actually, using general purpose languages (including Ruby) to build applications that access relational databases, like Oracle, is fairly common. That's why most general purpose languages have database libraries, and why most OO general purpose languages have multiple competing ORM libraries. If no one used these languages to access data in their big databases, the libraries wouldn't be so widespread. > Once other people have access to the data then the OOposition is undermined. What "OO position"? How is it undermined? > > Encapsulate private program data but leave shared business data to > databases. If you are using an ORM (or even just a lower-level database API), you are leaving the data to the database. If the data wasn't being left to the database, you wouldn't need a database library, ORM or otherwise, to access it. > > My other concern is why build your own wrappers when relational > databases already have excellent wrappers built in (you won't beat SQL) > and millions of man hours of optimisation code. SQL is not, obviously, a wrapper around SQL. And, yes, you can (easily) beat directly coding every database oriented task in SQL when you are trying to build an application in a general purpose language which accesses data held in a relational database that uses SQL, just as you can do better than handcoding the HTML for every possible task and result when writing a web application in a general purpose language, even though HTML is an excellent language for communicating to a web browser what you want it to present. > If you are not familiar with databases then by all means use an ORM but > I would have thought most developers would be better served by filling > in that knowledge gap at an early stage. I actually know relational theory and SQL (not that the latter is a very good implementation of the former, but that's pretty far off topic) much better than I know any particular ORM library; but for most database tasks from a language like Ruby, I'd prefer to use an ORM. Using an ORM isn't an alternative to understanding databases in general, though it is a way of abstracting the particular underlying database. > If you're just writing a shopping cart or social networking forum etc > your data might be quite simple but if you moved say to monthly billing, > discounts, credit limits, then I think it starts to get like eating food > with chop sticks - entirely a dodgy idea. More complex tasks that are beyond the use cases which motivated the design of an ORM are likely to require some custom SQL coding whether or not you use an ORM; on the other hand, more complex systems benefit the most, in general, from abstraction in the application level rather than using pervasive low-level coding. If you understand the SQL, and the ORM is extensible (which, given the nature of Ruby, is usually the case with Ruby-based ORMs) it may be better to use the SQL knowledge to extend the ORM (or at least the particular model classes involved in the more involved tasks) than to try to directly code the SQL for every task all over the application.