|
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.
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.