Performance Issue with Multiple Joins :-)

Question

Hi there! I have a dilemma over using multiple joins...and I am not sure whether there is any alternative to this. Please help me out if you can..
I have a table DATA having 100 columns and 2 million records and I have another metadata table Code_Mappings. The issue is with migration of this data from upstreams to downstreams.
Columns of DATA table is
a,b,c,d,e,f,g,h.......ca.cb.cc.cd.....dz.
Code_Mappings table is
Source_code |Target code | category
The problem arises when I join the metadata table for multiple joins..
Around 75 columns out of 100 are category questions i.e I need to replace all Source codes in the data of those category columns with target codes WRT categories..
Suppose A, C,D,I,J,K,L,W,X,Z,AA,BH are country category.
My query to fetch data from DATA for column A would be
Select decode(d.A, cm.source_code,cm.target_code,d.A) from DATA D,Code_Mappings CM where cm.category like 'country' and d.A=cm.source_code;
In the similar way, I may have to join the same table for category 'country' for n no of columns if those columns have category as 'country'.
Is there a alternative to use this table once and use the decode, mapping logic multiple times on columns..? Please let me know if there is anyways I can do it so that performance is enhanced in a significant manner.
Another Issue is:
Whenever the Column value is some junk, that record doesnt get fetched. In the above query, you can see that where clause has a condition of "d.A=cm.source_code" which not only filters out these required records but also avoids cartesian product.
The basic requirement is all records should get fetched. I do not want to filter out anything.
Please help me out.
Thanks
Mahesh

Answer 1

1) I'm not a JD Edwards person, but I would wager that if you're to the point where you have consolidated all the schemas to a single instance that it would be possible and preferrable to consolidate everything further into a single schema. I have to believe that JD Edwards provides tools to restrict what bits a particular branch can see without requiring separate instances.
2) What data are you accessing exactly? Are you always accessing data for a particular branch? Or do you need information from every branch?
3) Is your application logging in as a single user? Or will there be 1 application user for every JD Edwards schema?
4) Are you deploying your PL/SQL into 10-20 different schemas? Or into just 1?
Whether or not you are explicitly using the schema name, Oracle will have to do a hard parse of every logically distinct SQL statement. Two SQL statements that access different tables that happen to share the same name are logically distinct, so your shared pool will end up with 10-20 copies of the "SELECT * FROM <<some table name>>" SQL statement if it is executed against every instance of <<some table name>>.
The question may be whether it is better to explicitly provide the schema name or to rely on synonyms. You generate the same number of hard parses either way, but explicit schema names may improve latch contention during parses if Oracle has to do a lot of synonym resolution. Not many people/ applications are really hurt by this latch contention, though, so it is very hard to say whether this is a legitimate concern.
Justin