Home » Developer & Programmer » Designer » Arc relationship implementation in RAC environment
Arc relationship implementation in RAC environment [message #400421] Tue, 28 April 2009 02:24 Go to next message
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 Go to previous message
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

Previous Topic: hello every body here
Next Topic: generate problem
Goto Forum:
  


Current Time: Thu Oct 02 04:58:04 CDT 2014

Total time taken to generate the page: 0.15950 seconds