Shouldn't there be some sort of cache like for correlated subqueries, so if
there is an answer for some parent key, there should another query against the
child table not be scheduled for the same key? (Doesn't make much sense for
DELETE processing, maybe, because the parent key should be unique, but for mass
UPDATEs or INSERTs and lookups on the parent table).
And, if the child table on DELETE is empty, no other requests should be
scheduled?
Anyway, this is always the dilemma with RI: if you let the database do the RI
controls, you may have a performance problem, because the database does it
always. If you let the applications do it, you can control when and how often it
is done, but you are in danger to lose some places where it needs to be done,
and so you have no 100% security. And unfortunately, you have to decide it very
early in the project stage and it's very hard to change it later.
Kind regards
Bernd
Am 27.04.2011 23:06, schrieb D.S.:
> It may actually be getting this information from the spacemaps, but
> partition independence dictates that each partition has its own spacemap
> pages, so for every row on your parent it needs to consult at least 1
> spacemap from each of the 40 partitions.
>
|