RE: Changing column names?

Reeve,

Did you and I work at the same company, in the past...  LOL...!

This really describes my experience, as well.

Only difference is that where I got the bulk of my experience, we had an
EXTREMELY flat management.  We reserved the white boards for the really long
projects.  Otherwise, a few department heads would get together and map out
the scope of the projects.  I now think it unusual, but our users were both
spoiled and impatient...  A long project was anything that took over a
week...

Since the companies moved to *nix, and lost all the experienced, quality 400
people, a few have admitted they've found out how spoiled they were...  I
came to appreciate that better myself, after I left the place.  Lists like
these really could've helped me, back then, to see what REALLY goes on out
there, in TRW.  Was /way too/ focused on day-to-day problems, back then, and
wore too many hats to allocate sufficient time to investigate other shops...

:-)

jt


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Reeve Fritchman
> Sent: Saturday, November 17, 2001 11:45 AM
> To: midrange-l@midrange.com
> Subject: 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.
>
>
> _______________________________________________
> 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.
>