Re: Destroying related objects doubt ... basic oop question

On Thu, Aug 13, 2009 at 7:26 AM, Mike Stephens<[e-mail]> wrote:
> Christopher Dicely wrote:
>> =C2=A0the =C2=A0data 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 undermin=
ed.

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.