Changing column names?

Sounds like we're using technology to address some application
knowledge/design issues.  The only column names I've ever changed in 18
years are the ones I named improperly (I failed to follow my own standard).
Files moving to other libraries...well, what are library lists for?  Fields
moved to other files?  See first sentence!  Data moving to another machine?
That's an "It depends".  Operators deleting data?  Why does an operator have
that authority, and why would any designer allow such idiocy?

Not that your concepts are bad, Joe, far from it.  You've offered an
interesting perspective on design, but you've got to learn how to let
go...it's not good when you keep your feelings all bottled up :).  "Rogue
programs breaking in and attacking my data"?  Sheesh...are we talking alien
conspiracy or what?  Most of the justifications you've offered are not under
the bell-shaped curve where most business applications reside.

The real application development issue is getting the app built right the
first time, and IMHO the app is designed in a room full of whiteboards,
flipchart-sized Post-It's, and application advocates...and then the app is
prototyped.  Yes, applications do change; in my industry-specific business,
99% of the changes I see are "additions" (new data elements, new business
rules) to functionality already in place.

Decoupling presentation services, database management, and business rules
enforcement makes a lot of sense with an application supporting many
thousands of users; in this case, it's likely you'll have (or end up with) a
non-homogenous hardware environment.  When the hardware costs are much, much
greater than the software development costs, the application design has to
take this into account.

-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of Joe Pluta
Sent: Saturday, November 17, 2001 9:57 AM
To: midrange-l@midrange.com
Subject: RE: ODBC (was RE: Green screen - it's time is over )


> -----Original Message-----
> From: Brad Jensen
>
> I have no idea why you would want to change the names of columns,
> I would think that would be very poor programming practice, if you
> mean the names of columns in tables. It will sure be a surprise to
> the other people trying to access the database if you do.

In the real world, though, column names do change.  Files are moved to other
libraries.  Data is moved to another machine.  Fields are moved from one
file to another.  As you say, changes to your database require every program
that relies on the database layout to be changed.  That's the reason I
recommend that only one program (the server) understands the layout of the
data.  That way, database changes have a minimal effect on the rest of your
application.


> Create new tables, columns, indexes
> Populate the rows with data
> Delete and modify column structures
> Run most any sort of sql
> Create stored procedures
> Execute stored procedures with parameters

With the possible exception of executing a stored procedure, I would never,
ever want a client program to do any of these things.  There's simply no
reason for it.  The only things that should ever touch my data - and
especially my schema! - are programs on my server under my control.  If I
open this up to the client, any rogue program could theoretically break in
and attack my data.

Anyway, you and I have slightly different views of things.  Mine comes from
dealing with clients calling up in the middle of the night because some
operator deleted their data without backing it up.  I have seen companies
literally go bankrupt because of loss of data. Those companies are going to
be a bit mroe sensitive to the idea of data access, and less amenable to the
concept of allowing a client program to delete columns of data.


> And most importantly,
>     understand what is going on when you read the code

Readability is in the eye of the beholder.


Joe Pluta
www.plutabrothers.com

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.