Home » APEX - Making an example out of it.
Written by Kevin Landon on Thursday, February 28th, 2008
Categories: Examples and HowTo's

So, I’ve installed APEX and worked through the 2-day DBA guide, and basic tutorials on creating an application and deploying it. And after all is said and done, it works, just like hte guide says. Overall I am fairly impressed with the simplicity of the APEX interface, although there are a few small minor points about it that caused some concern. Note these are my own views based on the instances I have seen, observed or performed, and may or may not reflect any particular setup.

A few things they never really tell you in the install or DBA guide, or tutorial is about user creation, specifically developers. As I found out, if you create them wrong, or under the wrong admin account, they can’t really develop much of anything that actually works. And speaking of administration, it is obvious that while they pared down a lot of the features of Database, and simplified many of the operations, there is still the overbearing influence of pure Database and all it entails.

In large deployments and companies, with IT departments that can number over 100 people, the design of having a separate Network, Systems, Database, and Portal (applications etc) Administrators makes good sense. No one has all the keys to the castle, which improves the security of the overall system, as well as simplifying it, as large corporations normally can expect enough load for each segment to keep them busy without having to do the overflow of another job. In smaller settings however, say a company with an IT staff of 15 people, cross administration (Network and System admin is the same person) becomes more visible, partially for monetary reasons, but also since the total workload is low enough that doubling up admin tasks is how you stay busy. While APEX (on a Database Express Edition) reduces the need for multiple people, there is still a more or less designed separation of admin powers. the APEX Administrator account, the SYS account and SYSTEM account are each different, and needed for specific functions of operation. This also doesn’t get into the creation of an owner/administrator for each created workspace. This is where you can see the influence of full blown Database in the APEX/XE setup.

Don’t get me wrong, it’s fine to not have to worry about the OID, the superuser account, the multi layered security, and all that is associated with it on full DB. And since you can upgrade the DB from XE to full DB (Standard or Enterprise) it’s merely a matter of semantics, and slight re-gearing as it were to wrap your head around APEX. Oracle also states you can develop applications and reports with little to no knowledge of SQL or PL/SQL. The PL/SQL part is correct, but the more you do know about either, or both, the better off you will be, and the more rapidly you can develop and deploy your projects. With a myriad of tools at your disposal it is possible to build an application with only the base table structure in place, and no real data, and use the application itself to populate and load data in. Granted this makes testing more arduous during the design phase, but it is possible.

Onward and forward we go, now to create an application from scratch with my own data and see if I can make it work.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

You must be logged in to post a comment.