I have a pressing question. Which one has the most value in the IT industry: database administration, PL/SQL or (Oracle) Forms developer? I am going for training and confused about what to do. I have a bit of knowledge on databases and PL/SQL. I love programming too and would love to grow as an applications developer, but in the end one would like make money with it. What do you think?
Regarding Oracle Forms, I see fewer and fewer jobs requiring it. It was never really prevalent in the industry due to its high entry costs early in its availability back in the 1990s. Then in 1997, Oracle did make Forms and Designer available free for download to students and evaluators. However, the significant memory footprint for Forms (plus Reports and Graphics) prevented some companies from deploying it, as they would have to upgrade all of their PCs just to run it. Later, Oracle did a complete rewrite of Forms, basing it on their J2EE framework. Today it seems more of a niche tool. Here in Pittsburgh, for example, I know of only one company that actively does Forms development (internally). They had adopted it years ago, but it's slowly being obsolesced and phased out in favor of other, newer Web technologies.
Oracle PL/SQL is used in just about every shop that has an Oracle database, especially those that develop Oracle-specific applications (either for internal use or for external customers). In contrast to Forms, Just about every Oracle-based company here in Pittsburgh uses PL/SQL in some manner or another. PL/SQL is used not just in applications but also in DBA groups, to automate collection and reporting of the databases' health, perform complex tasks, etc. You can build powerful APIs in PL/SQL for UI developers to leverage. Rather than have the UI developers write and embed their queries in application code, they can code against a PL/SQL API. This hides implementation details and speeds development, especially when UI and PL/SQL developers are teamed up (paired) to design and develop in parallel. I have seen this done successfully in several shops, where PL/SQL packages are designed and built to support application development.
The DBA role is a fairly different creature than PL/SQL developer. Not all DBAs use PL/SQL, although I think they should have at least some familiarity with its capability. Some shops havA developers, a specialized PL/SQL programmer role whose job it is to support the DBAs' efforts by building specific tools for them.
Not everybody wants to be a DBA. Operational DBAs typically are on-call (carry pagers), observe and maintain the health of many databases, perform backups and restores, build and migrate new databases, etc. They are responsible for the ongoing health of the database. DBA architects perform an advisory role (in addition to the more mundane operational activities) to assist UI developers to accurately model and build high performance database schemas and applications. A DBA isn't just a highly paid database babysitter any more. They can be counted on to weigh in on design and implementation discussions early on and throughout a project's lifecycle.
Having some DBA task familiarity makes for a better PL/SQL programmer. It's important for a PL/SQL programmer to understand what's going on under the hood. While UI developers tend to think of the back-end as generic and de-coupled from their front-ends, PL/SQL programmers have to consider how the back-end and front-end (and often the middle-end) integrate with one another, for performance, scalability and maintainability.
This was first published in January 2011