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
*
*************************************************************************
