Previous Entry | Next Entry
Chet Justice's manifesto, of sorts.
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.
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 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. ;-) ]
Thanks Lewis (I'm in Tampa now if you ever want to get together).
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?
Nicely put Chet.
Invite Friends to Discussion
Also in the ITtoolbox Community
More from this Author:
Keyword Tags: database vs app, database, application, APEX, SQL
Trackback URL: http://blogs.ittoolbox.com/cgi-bin/mt/Jindyik5.cgi?tb_id=15096
Copyright © 1998-2007 Information Technology Toolbox, Inc. All product names are trademarks of their respective companies.
Information Technology Toolbox, Inc. is not affiliated with or endorsed by any company listed at this site.