Apex SQL Code

Question

Hi guys:
I'm not an expert in SQL and I saw what Apex is doing is very useful.
Can I see the SQL code generated by Apex -by woking in Apex environment-

Answer 1

With a little research on tracing, you should be able to easily get back the SQL statements that APEX uses, but not the PL/SQL. The PL/SQL is wrapped, so you won't be able to see that. With that said, the SQL is nothing special. That's is not a knock on the APEX team (I used to be on it), it's just nothing you couldn't find examples of throughout asktom.oracle.com.
The APEX Team follows some pretty simple and well known design principals that keeps the code very efficient. Above all else, the principal of designing the data structures for how they'll be accessed, not how they make sense to the developers is key. Since the nature of the APEX data structures is 95% read, they may make the edit of a page less efficient and do some extra work up front to make the display of that page as efficient and fast as possible.
In keeping with that theme, they will create indexes on tables that makes the reads as fast as possible, but again may make the create / edit of a page much slower due to additional index maintenance.
You'll notice that all of the tables have a single primary key column; none of this 3 column composite key stuff you see discussed all over this forum. This makes foreign keys, queries, updates, and deletes much easier on the programmers. I've stopped responding to the questions about DML on tables with 3+ composite key columns or tables with no primary key at all. IMHO it's just not good database design, but people get very defensive of their data models. So, I've given up. My advise to you is to stick with a single, random primary key that will never ever be changed. Also please ignore the flame war this is likely to start in this thread ;)
I'm also a big believer in instrumenting your code. This is definately Tom Kyte's influence on me, but also the APEX team's. Notice that APEX has a debug mode with timing, so they've clearly instrumented their code. You can see an example of this in a wiki project I'm working on now. Take a look at this package. Notice how every procedure in there has 2 "$IF $$debug $THEN" blocks, 1 at the beginning and one at the end. This is using conditional compilation and allows me to recompile this package with debug on so I can see how much time each procedure is taking. I can't stress this enough, instrument your code.
Other good SQL principals to keep in mind include:
- Don't call functions in SQL predicates (where clauses) as it's VERY slow. If you need to call a function such as upper, make sure you use a function-based index on that column.
- Do everything in bulk SQL operations that you can. A lot of people resort to PL/SQL loops for processing. Tom Kyte refers to this as "row-by-row or slow-by-slow".
- Don't call functions in SQL at all if you are returning a lot of rows. That function will be called once for every row and you'll context switch between SQL and PL/SQL once for every row.
- For your most popular queries, particularly on "wide" tables, if you index every column in the select and predicates section, the data can be returned from just the index without going back to the table.
- Materialized views are your friend when you want to pre-compute the answers to your most expensive questions.
- Buy Tom Kyte's books. This is not a commercial for them, but the philosophy contained in those books has absolutely influenced the philosophy of the APEX team... They all used to work together on a daily basis.
Hope this helps,
Tyler