|
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. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.