Re: Mixing OO and DB
Date: Sun, 10 Feb 2008 16:29:35 -0500
Message-ID: <m28x1ssdog.fsf_at_spe.com>
frebe <frebe73_at_gmail.com> writes:
>> >> >> 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?
That's one possible semantic. Another is to update post-commit,
in order to minimize the performance impact of materialized views on
the underlying schema.
> Having redundant data may also impose certain performance costs that > may or may not be acceptable.
Certainly, but denormalization for performance is a relatively common technique. It does provide value in some environments.
>> > 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.
Normalization is certainly to be preferred, but the benefits of
it must be balanced against its costs.
>> >> 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.
I've already done so. Denormalization for performance. Addition of new functionality. We could add refactoring to take advantage of new (or existing but unused) functionality of the RDBMS. Support for additional reports (a subset of addition of new functionality).
I'm not sure where you're going with this. What point are you trying to make?
>> >> 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.
That ignores the fact that OO is about implementing behavior. In
many systems there is no need for the relational model, except as an
interface to other systems that happen to be database centric.
Can you provide an example of an RDBMS that integrates with classes as you describe?
Sincerely,
Patrick
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Sun Feb 10 2008 - 22:29:35 CET