More analysis of the Oracle Applications R12 sample database, VIS.
LOTS of: Objects, Packages, Triggers by Table, and Source Code
The schema, APPS owns: 51284 PACKAGE BODies, 32991 VIEWS, 4183 TRIGGERs
There are over 57 million lines of source code in the APPS schema alone!
I did some initial schema analysis on Oracle Apps R12 sample database, VIS.
VIS uses hardly any primary keys, many non unique indexes, and a LOT of package and triggers.
Lots of potential for data integrity and tuning issues.
Reviews of some really useful PC performance testing software that I’ve been very pleasantly surprised by.
If you want to make a Cobol system, write your system with flat files and use Cobol. Or C. The system will run much faster than using a database.
MUCK: Massively Unified Code-Key, Generic Three Table Data Models cause lots of problems: Awful performance, Pivots, Require multiple inline views, data type Issues, really complex inserts, increased people time, cost, and create a Cobol system. Just say no!
Creating a LOB for every customer record, whether it was used or not, caused some serious problems.
There are three ways to implement Referential Integrity in a database system. Primary and Foreign Keys, Triggers, Application code. And each method results in different database performance.
A cartesian product in a single query can make the whole server go slow. The other problem is the result sets, which come back many multiples too big.
No gizmo tool will help you with a cartesian product. No query analyzer will tell you that you have a problem, or how to fix it. Cartesian products are one problem area that only observation, knowledge, and good SQL skills will overcome.