Re: Help, my developers are killing me with varchar2(4000)

RogBaker_at_gmail.com writes:

> I have a developer that created some tables in a development instnace
> and wants me to promote them to QA. I took a look at them, and nearly
> every column is varchar2(4000). I am pretty sure this is overkill for
> most of them. I know it takes up as much room as the data, but I just
> don't like this design philosophy. Does anyone have any references/
> urls saying this is a bad idea to design tables like this? It has been
> my experience that you get bad data by allowing columns to contain
> more data then what it should really hold.
> Thanks in advance,

OMG - are som eof our developers working for you as well?

I have this arguement regularly, particularly with web developers for some reason. I'll be there are no check, fk or any other referenctial integrity constraints in there as well!

I think part of the problem here is that many, particularly young and often web oriented developers just use the database as a 'bit bucket'. We had exactly this issue recently. Not only were all the fields varchar2(400) (including ones used to store dates, timestamps, and numbers - even unnatural primary keys that used sequences to generate the unique key) the tables were called things like bens_data where Ben is one of the developers. Worse still, all the logic reagarding the data relationships and constraints was handled in the client app code (more often than not java/jsp),

I think essentially, it is a combination of laziness (can't be bothered actually doing any formal analysis and data modeling) and ignorance (don't even understand when I try to explain why its bad design).

I regularly try to explain the benefits of using the facilities of the database to assist in managing your data e.g. don't have to replicate the logic in every client app and therefore don't have problems in keeping things consistent between apps, providing valuable information for the poor suckers that end up having to maintain the apps etc. All I get back is that their way is more flexible and quicker. My way is slower and harder to modify. Of course, they don't consider maintenance.

A big part of the problem is lack of experience. For some reason, there is this growing belief in some management quarters that these young recent graduates, who are half the cost of more experienced developers, are doing excellent work - I mean, seew snazy that web page looks. Of course, when they realise the app is becoming nearly impossible to maintain, the original developer has moved on and so has the manager. Some new manager and new recent grad is responsible. they end up bitching about how bad the previous lot were and then go about re-implementing the app because its too hard to maintain. Unfortunately, they just do the same thing all over again and the whole process starts another cycle.

All I can suggest is to keep pushing your case and don't get too frustrated when you can't get any support for your arguments. If your really really into frustration and pain, start talking about the benefits of developers using things like dbms_application_info and providing some help to the DBAs who keep getting hassled to solve performance problems etc. I'm not a DBA BTW.

Tim

-- 
tcross (at) rapttech dot com dot au