Re: Mixing OO and DB

From: frebe <frebe73_at_gmail.com>
Date: Sun, 10 Feb 2008 07:48:55 -0800 (PST)
Message-ID: <6bf1cba1-d864-4970-8c38-f3cf24d8a323_at_n20g2000hsh.googlegroups.com>


> >> >>      Denormalization for performance of a particular application
> >> >> is a perfectly valid example.
>
> >> > Unless your database supports materialized views.
>
> >>      And if your application can accept that the data in those
> >> views may be out of date.
>
> > Unless you do "refresh on commit".
>
>      That still leaves a window during which the data can be out of
> date.  It also imposes certain performance costs that may or may not
> be acceptable.

Doesn't "refresh on commit", refresh the materialized view within the transaction?

Having redundant data may also impose certain performance costs that may or may not be acceptable.

> > Having a denormalized schema is also a good way of introducing data
> > that is out of date.
>
>      How so?  Regardless of the normalization of the schema,
> operations should be ACID.

But it is up to the application programmer to make it ACID. Like you said you might have other less well-written application accessing the same schema, introducing update abnormalities. Database normalization has many benifits. Denormalization has many disadvantages.

> >>      With a single application database, distributed applications
> >> demonstrate additional trivial scenarios.  A new service or agent
> >> might need data that is not of interest to existing services and
> >> agents.
>
> > The reason why the schema change is that the behavior
> > change. Behavior and schema doesn't change for different reasons.
>
>      As I pointed out, even with a database used only by a single,
> albeit distributed, application, there are reasons for the schema to
> change that do not require existing behaviors to change.  

Then it wouldn't be any problem for you to give some examples.

> Similarly, there are behavior changes that do not impact the schema.  

I don't think we have a disagreement about this one.

> >> >> > O/R mapping is not the best way of mixing together DB and OOP.
>
> >> >>      What alternative do you recommend?
>
> >> > My recommendation is that if you already are using a database,
> >> > you should not use objects as data structures. That is job is
> >> > supposed to be done by the database.
>
> >>      So your answer to the question "How do I mix OO and
> >> relational?"  is "Don't use OO."  Succinct, but not particularly
> >> responsive.
>
> > I didn't say that. Like I said before, classes may perfectly well be
> > used for defining types for relational attributes. Objects map to
> > attribute values, not to relations.
>
>      Do you have a reference to this technique being used in practice?
> I'd need to see the details to understand what you mean.

What part didn't you understand? Every relational attribute (table colum) has a type (domain). Classes are suitable for defining types. Examples of relational attributes are dates, telephon numbers, zip codes, images, audio clips. But entities like customer, employee, invoice, are not good candidates for classes, if you are using the relational model.

//frebe Received on Sun Feb 10 2008 - 16:48:55 CET

Original text of this message