Hi Neil
I understand what you are saying, I guess I was not explicit enough. What I
was wanting to ask is as follows
Consider the following in an order management system
a) In database, we often have a Items table that contains, among other
fields, ItemCode and ItemDescription
b) We have a OrderItems table that contains, OrderNumber, ItemCode, Quantity
etc.
Now these are mapped (for now lets say one is to one) with Items and
OrderItem classes. While instantiating OrderItem, if I keep a readonly
attribute called ItemName, will this be OK in OO terms or each time I need
to display the name I would need to instantiate an Item object and then get
the Description attribute?
My take on this was that an objects data need not reside in one table, it
can be made up from any number of columns from two or more tables. It is the
duty of the persitance layer to properly store/retreive the data and as such
the object should not be bothered too much about this fact.
If this holds true then I would see no harm in having some redundant
attributes - readonly if you please. Am I wrong on this?
Pankaj
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Neil Pitman
Sent: Monday, November 27, 2000 3:12 AM
To: [EMAIL PROTECTED]
Subject: Re: (ROSE) Designing Objects
Pankaj Chatterjee wrote:
> Hi Folks,
>
> I was wondering :-
>
> While designing a database, stress is given on normalizing the data
> structure. Do we have something similar in OO terms while designing
objects,
> or is it acceptable for two related classes to have some common attributes
?
>
> Thanks
>
Hi Pankaj,
As in databases, there is theory and there is the, errr, real world.
They work similarly in
this respect. And just like DB's, in objects, you can have redundent
data, but more likely
than not, you'll be sorry.
Arguments against redundant data:
1) Consistancy - the data that should be the same is not - the update of
one object is not
propagated
2) Consistancy - The change of data takes a real amount of time to
propagate to the other
copies so a window of inconsistancy exists
3) Ownership - where is THE correct version of the data.
4) Transaction management (Consistancy/ownership) - If I want to update
the data, (how) do I
lock all the copies?
5) Consistancy - If the common data is actually summary data, how does
it get made in the
first place and how does it get stale?
6) Change propagation - how does the data flow from the source to the
copies? How does the
stale data know to be refreshed?
Arguments for redundant data:
1) Far away data - the source is too far away (in time) to make meet
performance. It could
be out of process, on other servers, in another format, require some
lengthy protocol to get
such as a look-up or security check. (But how do you get the Update()
event then?)
2) Doesn't really matter in the time frame - I mean, how many
states/counties appear or
disappear per day?
3) It isn't really the same data anyways - the changes in the tax rate
do not apply yet
because the transactions apply to another accounting period.
4) Availability - you need redundancy in case of a hardware or software
failure. This is
serious business so you should know what you're doing (i.e. don't fish
for this solution on
chat groups)
Just a hint if For #1 is enchanting enough to , remember Neil's first
rule of performance:
"Make it work, then make it fast."
Don't put the tuning and caching in until you know that 1) the programme
is functionally
correct using one copy of the data, 2) it is really too slow, and 3)
putting in the
redundent data will make it fast enough.
Oh, and make unit tests that just test the redundant mechanisms.
Neil Pitman
[EMAIL PROTECTED]
+1.514.863.5465
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
