My Utopian Development Environment

 

Some thoughts about my perfect development environment. Of course it will never happen 🙂

Compulsory PL/SQL APIs
Client application developers would have no direct access to tables. Not even for queries. All access would be provided by PL/SQL APIs. I like this because:

  • It removes the need for triggers as all inserts, updates and deletes are wrapped in APIs. Instead of writing triggers you simply add the code into the API. I loath triggers.
  • It prevents people who don’t understand SQL writing stupid queries. All SQL would be written by PL/SQL developers or DBAs, reducing the likelyhood of dodgy queries.
  • The underlying structure of the database is hidden from the users, so I can make structural changes without client applications being changed.
  • The API implementation can be altered and tuned without affecting the client application.
  • The same APIs are available to all applications that access the database. No duplication of effort.

J2EE abolished
I like Java, but I dislike J2EE. When I look at the way J2EE applications interact with the database it worries me. Perhaps I’ve been unlucky, or perhaps I’m missing the point, but I think it’s shocking. Using container managed persistence (CMP) to generate SQL on the fly worries me. I want to know at development time what is going on. I want to be able to cut and paste the SQL, not try and capture or trace it during a run. At least with bean managed persistence (BMP) you get this, but Java developers seem to avoid BMP like the plague.

Even when J2EE developers use BMP with calls to PL/SQL APIs, the containers have some strange ideas about what’s sensible. To update a record the container requests a query, update and requery of the data, rather than just a query and update. What’s this extra work for? I know what the state of the data is. I’ve just updated it. Even if someone does sneak an update in after me, the bean is being destroyed so the extra query was pointless.

I’m not saying that J2EE is pointless, I just think that 90% of the people out there don’t know, or care, how badly their applications interact with the database. Maybe some Java guru will tell me why I’m talking rubbish, but I can only judge this on my experience and that tells me that J2EE applications are not performant.

Miscellaneous
Just a few extra points to throw into the mix.

  • All client application developers would understand the rudiments of SQL, PL/SQL and DBA work. They don’t have to be experts, but they should understand the basic concepts.
  • All DBAs would understand the rudiments of client application develpment work. Once again, they don’t have to be experts.
  • All DBAs would be skilled at SQL and PL/SQL. I feel they should be the best in the company, but I know others would disagree. Oracle has now dropped the requirement for PL/SQL in the OCP DBA syllabus. In my opinion this is a mistake.
  • Managers would understand when a decision should be made by the techies.
  • Techies would understand when a decision should be made by the management.
  • People would share ideas and information, rather than trying to empire build.
  • Companies would encourage reskilling of employees.
  • Techies would want to keep there skills up to date, or make way for someone who does.
  • Applications would be planned, designed and built using more formal methods, not RAD or iterative development.

Perhaps the most important point is that I would be presented with lavish gifts whenever I entered the room.

Cheers

Tim…

Author: Tim...

DBA, Developer, Author, Trainer.

13 thoughts on “My Utopian Development Environment”

  1. When you find that place, let me know and I’ll start the next day. 😉

    Compulsory PL/SQL APIs
    Client application developers would have no direct access to tables. Not even for queries.
    I’m kinda with you on that with an exception. I don’t want to write a PL/SQL refcursor every time one of my semi-intelligent “power users” want to get access to the data. I’d rather create a view and give them access to that view. I can still maintain the transparency of the underlying model while providing them a way to query,sort,group,and filter to their heart’s content.

    generate SQL on the fly worries me
    Anything that generates SQL on-the-fly worries me, not just Java. You can write bad code in any language.

  3. I liked the list.

    It struck me recently that a PLSQL API to the DB would enforce the (much forgotten) software engineering principles of;

    1) make software components modular
    2) software modules must carry out a very specific task (and be very efficient at carrying it out)
    3) each software module should be loosly coupled (to limit dependencies)

    In my experience most application code I see is modular. But designers/coders seem to forget that the database is another piece of software and should be subject to the same design criteria. Putting an API around the database is good for all the reasons you state. It also is big step towards a secure data storage environment.

    mathewbutler

  5. Well, there are many more users than developers or DBAs, so your Utopia might have a serious built-in bottleneck.

    I think analysts should be the ones who judge stupidity, there’s no way to pre-judge technically – if you do the latter, you are letting the technology define the app, which is backwards. And if users want to cartesian-join all the tables, I say let them budget their own pc DW and ETL and have at it! They might learn something about what they really want to do.

    I think defining a “dodgy query” is much harder than it might seem at first glance. If it wasn’t, there would be something more than “resource limits” in the db, wouldn’t you say?

  6. Joel Garry said…

    Regarding dodgy queries. I agree, there are diferent types of dodgy queries. I’m not so concerned about those ones you didn’t see coming. Some things will always get to production before you can spot them. I’m talking more about the blatantly stupid things people do because they are testing with 3 rows in a table. I can avoid these “most” of the time 😉

    Regarding analysts. I view DBAs, developers and analysts all as the same thing. In my opinion, any one of these jobs requires skills that cross into the others. I’m not talking complete understanding, just wareness. From that perspective I think all these roles should be able to identify “stupidity”. Yes, their perspectives may be different, but equally capable and valid.

    Perhaps I’m wrong, but it’s my utopia 🙂

    Cheers

    Tim…

  7. “I’m not saying that J2EE is pointless,”

    Forgive me, but that is EXACTLY what I am saying. The technology is deranged,totally over-engineered for the very little it does, is impossible to manage at large development projects and is being pushed by total ignorants.

    Sorry but someone has to say it and it might as well be me: one of little consequence.

  8. I hear what you’re saying 🙂

    I’m not denying the need for enterprise class development frameworks, but I would question whether most of the projects I’ve ever worked on need them.

    If a copany like Yahoo can get away with Perl and PHP I doubt most companies need to venture into the J2EE teretory.

    Cheers

    Tim…

  9. Don’t throw out J2EE just because one poorly done, but well advertised piece is bad.

    You’re discussing EJBs as if they are the only piece in J2EE, but there are lots of other good things to choose from.

    Have a look at Spring, now there’s a nice bit of core utopia to start from, and then maybe add on Cocoon … and never once use an EJB!

  10. How many months late is this comment?

    Anyway, just wanted to add that now that MOST of the SQL vendors support some form of server side procedural language, that removes one of the major arguments against wrapping data in procedures – that it ties you into a database vendor.

    (Although that always seems to me to be a developer requirement or stem from a religious view on OO app structure).

    Anyway, it could become a useful ‘pattern’ for hiding differences in SQL – hidden in the package implementation – if you stuck to a consistent interface / naming convention across the different vendors. B
    (Of course not all of them support packages, but I think something similar can be achieved using namespaces).

  11. Of course stored procedures tie you to the database vendor, it is non trivial to translate from PL/SQL (Oracle Stored Procs) to T-SQL (MS-SQL Stored Procs).

    An standard exists (http://en.wikipedia.org/wiki/SQL/PSM) but nobody cares.

    Your utopia would be my nightmare most stored procedure languages are very limited, most of them not even support relvars. I mean, stored procedures have its place, and are the best tool for some task, but having them as the only option would be awful

    Maybe one day, someone with power will read The Third Manifest and we will finally have TRDBMs, until then, I am happy that I am not forced to code in PL/SQL.

Comments are closed.