Visit Citebite Deep link provided by Citebite
Close this shade

ITtoolbox Connection Manager
Try it today!

ITtoolbox Blogs
287,036 blog subscriptions
Welcome, Guest
What is ITtoolbox? A community where peers share knowledge about information technology.
{Start connecting. Take the tour }

Sign in to ITtoolbox

E-mail or User ID

Forgot password?  Help
Find Members

ITtoolbox Blogs > Confessions of an IT Hitman > Entry
Confessions of an IT Hitman
Blog Main | Blog Archive | Author Bio |
| Connect to this blog
Previous Entry | Next Entry
Chet Justice's manifesto, of sorts.
(Chief Architect) Posted 8/7/2007
Comments (8) | Trackbacks (0)

A longtime reader and APEX handy man sent me an email he sent to his CIO. It reminded me of an email I sent to my CEO years ago. Sometimes you just have to point out the facts. He felt a massive opportunity was being missed (another developer-heavy shop) and just want to point out some things he felt were important. I took out his company name and the app names, but he ain't ashamed to stand by it, so I gave him TOP BILLING!

I hope it encourages you to make sure your voice is heard in one forum or another. You're paid to participate.



I thought you might appreciate this. I recently sent this to my CIO...fortunately I still have a job. He's pretty open to my opinions (which is all I can really ask for).

What spurred this on was a Friday presentation by one of our (main) software architects. All I heard was Ruby, Java and C#. Not a thing about the database.

The one thing I did leave out was APEX unfortunately.



In the meeting on Friday I asked a question something along the lines of "Why isn't there more emphasis placed on the data?"

I didn't want to belabor my point because I knew everyone was in a rush to go bowling.

This is something of a manifesto for me:

From my point of view, I see two types of developers. One is of the application variety; they make GUIs and web sites. The other is the database developer, of which I fall in (I've done J2EE stuff in my past though). Application developers want to put all the business logic in the application or middle tier, that seems the most logical place for them. Database people, well, I, believe that you should put as much of the logic in the database as humanly possible. Get it as close to the data as possible. Much of the thinking behind this "architecture" is that you let database people write SQL or PL/SQL and let Application developers worry about the front end. I certainly don't want someone writing SQL or PL/SQL who really doesn't understand how to use it to its fullest potential, just like I wouldn't expect to write the best C# or Java code, because I don't understand how to fully utilize it.

Putting SQL (and PL/SQL) in the database gives you a few advantages:

Maintenance? The SQL is in one place, the database. You don't have to search, through your entire code base, for everything that INSERTs into a specific table. Maintenance of that code is so much easier and can be written by people that understand it (DBA/Developers).

Cost? How much do we pay for our Oracle license? I'm sure it's well into seven figures. Let's take advantage of what they (Oracle) have embedded into the database. Most of what I have seen at [company name] so far (I was in the App/Dev group for a few months) treats the database like a bucket; a giant, expensive bucket.

Why not use what we are paying for?

Oracle has written a lot of functionality that we could use;
i. Advanced Queueing, aka Messaging ? would be great to utilize for the [app name] workflow application. We wouldn't have to buy a COTS application (or pay consultants to help us).

ii. Change Data Capture ? Would allow us (Data Warehouse) to capture only the records that have changed in [app name 2]thus significantly decreasing network traffic and would mean month end would not take nearly as long as it does now

External Tables? great way to upload files, just create a table that maps to it and your done. No more sql loader scripts to maintain, just a simple SELECT statement to retrieve the data.

Data Integrity? Utilizing a well designed, constraint driven data model, you can create a system that won't get dirty data. Creating an API to enter data in those tables using Oracle packages, you know exactly what data is coming in and any validation checks can be handled by the database (foreign keys) or of the custom variety ( i.e. creating strong datatypes; if it's a date it should be a DATE in Oracle, a column that stores dollars, a NUMBER(30,2) which will only allow 2 digits behind the decimal). Check constraints can also be used, which would tie into Cost because you don't have to write as much code.

I've read many arguments for an against. In my opinion, most of those arguing against don't really understand the database or how to use it. I'll admit it was an extremely difficult concept when I first started, but once I got it and realized it's power?

Mostly this is about keeping things simple. My previous employer was a small state funded company. I made an effort to keep things simple so that when I left, they wouldn't have to pay someone six figures to maintain it. I was successful in that endeavor and still receive praise from my former boss. I am very proud of that. Things don't have to be as complicated as we sometimes make them.

Data is the most important thing we have. Applications come and go, but data stays the same. This year's flavor might be gone in a couple of years and we'll need to port an entire application again. If most of that logic is in the database, it will be easy to do. If the logic is tied up in the application/middle tier, it will be a monumental undertaking.

This has been brewing for quite some time. Please don't think I'm gunning for someone's job, I'm not. I just haven't heard anyone really argue from the database side.

8 Comments RSS for Comments
DevWins writes:
8/8/2007 #

Good for you. I'm one of the rare people who is the lone developer in a database shop and I'm in the position of arguing the opposite. But I'm glad to see you speaking your piece.

I know my database team doesn't like it when I suggest it makes more sense to do some of this outside the db (even like java stored procedures), but if I make a big enough stink, they let me try.

I think Dratz is good that he just wants people to think (and do something about it).

Live, learn, live some more.

Ralph Wilson writes:
8/8/2007 #

I come from a time when there was no distinction between applications developers, systems guys, database guys, and device driver writers . . . we did whatever it took to get the system up and running. <[i>Before I get someone's ire up,I am referring to "guys" in the CHicago sense of "y'all" or "we'uns" in the south . . . it is NOT a gender specific term. ;-) ]

I have always believed that there was no one tool and no one approach that solved every problem. <[i>"To a man who only has a hammer, everything looks like a nail."] I have been in shops where the only SQL statement that was available to the developers was the one that extracted the other SQL statements from the database . . . and we made it work. I have also been in shops (as in where I currently am) where the developers had little knowledge of SQL and there was no DBA/Database Architect/Database Developer to guide them . . . and they made it work (somehow, however ugly ;-).

I, too, think that there needs to be a collaboration between the front end developers and the back end developers (and, if you've got 'em, the middle tier developers ;-). Kudos for bringing it to the attention of the CIO. (If I didn't know he wouldn't listen or understand, I'd be doing the same thing here. ;-)

LewisC writes:
8/8/2007 #

Go Chet!


chet writes:
8/9/2007 #

Thanks Lewis (I'm in Tampa now if you ever want to get together).

I'm definitely all for collaboration, I think it's essential. My gut feeling is that the architects don't know much about the database.

Our CIO started in January and we are about finished with our "Stabilization" phase, then it's on the re-architecting many of our current processes. I initially thought it might be presumptious (you know, 30 minutes after I sent it...WTF did I just do?), but he was surprisingly happy that I had sent it. I am very thankful for least I have a voice.

wayTothinkItThrough writes:
8/9/2007 #

And when your told that you have to support a different rdbms you get to write all that sql again and god help you if you used anything specific to oracle/informix/etc?

SueC writes:
8/9/2007 #

Nicely put Chet.

I've always apprecaited a bright and talented dba who could put the db through its paces. The irony of it is that most developers don't know enough about the business rules until they come across them so late in the development cycle (What!? You didn't say anything about validating against those codes!....Uh, you didn't ask.) that they get added on as a second thought because the upfront work wasn't done by a good business analyst. At the my last company I was having to build all of the rules into the BI application metadata. Talk about burying them in obscure code! Just try and find them in a year or two...

I prefer to work with well rounded people who know all aspects of development well yet specialize in one or two. That way they recognize other specialists and everyone can work from the same high standard book - and use it to teach the new people.

....sigh...time to take off the rose colored glasses.

LewisC writes:
8/9/2007 #


I have worked in environments where many languages (in one case Cobol, C, Java and .Net) all accessed the same database (Oracle).

Languages come and go (frequently). Databases tend to remain.


chet writes:
8/9/2007 #

Thanks Sue.


I'm with Lewis on this one. If we were a software company developing software utilizing multiple databases, I might think that way, but databases tend to stick around.

I am an Oracle guy, but I would say the same exact thing about DB2, SQL Server, MySQL, etc. Use what you paid for (or didn't pay for). That was the point of my "manifesto."

You are not logged in, sign in to post unmoderated comments or join the community to create your free profile today!
Name:  (Will display on the site)
Email:  (Not displayed. No spam)
Lines break automatically. Please preview your message before posting.
If not logged-in your post will not appear until approved by a community moderator. To uphold community standards, comments that are inflammatory, offensive, or contain profanity or advertisements may be removed by the author or a community moderator.
Connect to this blog to be notified of new entries
Invite Friends to Discussion
Also in the ITtoolbox Community
Related Blogs
Related Groups
Related Articles at Wiki
More from this Author:
Blog This Digg This Email This
Print ThisRecommend This Blog

Keyword Tags: database vs app, database, application, APEX, SQL
Trackback URL:
About This Blog
A blunt, entertainingly informative blog covering technology topics from the perspective of a regular IT person. Focuses on life as.... (more)

Enter your email address to be notified of new posts.
No Spam (Privacy Policy)
Now What's Dratz Up To?
    Recent Comments on This Blog
    "@wtf, thanks for the customer-focus..."
    (Trying to get a refund on a video ...)
    (BioShock comic from Penny Arcade)
    "Aw, c'mon to Florida, we'll..."
    (SQL Saturday)
    "Thanks for the update, Dave.After..."
    (Quit Your Job and Play BioShock)
    "I got some solution to isolate..."
    (How to Use Oracle (18) - Excessive ...)
    Oracle (29) - Rants (25) - Required Reading (17) - The Interns (2) - Thursday Haiku (25) - Workshop (3)

    Disclaimer: Blog contents express the viewpoints of their independent authors and are not reviewed for correctness or accuracy by ITtoolbox. Any opinions, comments, solutions or other commentary expressed by blog authors are not endorsed or recommended by ITtoolbox or any vendor. If you feel a blog entry is inappropriate, click here to notify ITtoolbox.