| Arc relationship implementation in RAC environment [message #400421] |
Tue, 28 April 2009 02:24  |
cccc
Messages: 2
Registered: April 2009
|
Junior Member |
|
|
Hi all,
what is the best way to implement an arc relationship (XOR / mutual exclusive or polymorphic association)
in physical database design in a RAC environment?
e.g.:
Table table1 with 2 references, 1 joins to table2, the other one to table3 - the join is mutually exclusive = arc relation.
In further releases the number of relations to additional entities will increase.
table1 on will receive a huge amount of inserts (index contention, sequence problematic)
So, what will the experts recommend?
Having one table with 2 foreing keys joining table2 and table3 or splitting table1 into 2 tables, each of
them joining the according master table? Or some other solutions?
Thanks
Chris
|
|
|
|
| Re: Arc relationship implementation in RAC environment [message #400525 is a reply to message #400421] |
Tue, 28 April 2009 10:16  |
cccc
Messages: 2
Registered: April 2009
|
Junior Member |
|
|
some more info:
The point is, that I'm operating in an environment where no DB OO features are
allowed - no object types at all in DB.
My questions is more performance related. I'm talking about a high performance
trading system with a huge amount of parallel processes accessing data
via Eclipse-Link.
The table I'm talking about will receive millions of inserts a day:
Table1
( id number pk -- sequence generated
, table2_fk number references table2 - nullable
, table3_fk number references table3 - nullable )
Table2
( BusinessKey String pk
attribut1 ... )
Table3
( BusinessKey String pk
attributes ..)
The nullable FKs in table1 are result of the ARC - for every row only
one of the foreign keys are populated, the other one is null.
As a matter of fact, some more of those Fks referencing additional
tables will be there in the future.
My point is, that it maybe is a good idea (for performance reasons
and not in terms of data modeling) to split table1 into 2 tables:
I'm thinking about index contention and sequence allocation problems.
Or isn't index contention not a problem if one column will always be NULL?
As mentioned table1 will receive huge amount of inserts ...
Table1_2
( id number pk -- sequence generated
, table2_fk number references table2 - NOT NULL )
Table1_3
( id number pk -- sequence generated
, table3_fk number references table3 - NOT NULL )
Table2
( BusinessKey String pk
attribut1 ... )
Table3
( BusinessKey String pk
attributes ..)
Regards
Chris
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
