4 ms·

For what it's worth, the "what falls apart" line was intended to be tongue-in-cheek. Surely you must have known about the guy from Guam or the one living in Vi

by Harkins 18y ago

For what it's worth, the "what falls apart" line was intended to be tongue-in-cheek. Surely you must have known about the guy from Guam or the one living in Virginia but commuting to D.C. when you analyzed your app, right? Nope. For most of the apps I've worked on recently, we're pulling incomplete datasets that are augmented from other, slightly-incompatible sources and manual entry and must be designed and built to meet the deadline for a newspaper story. So I do the best I can to capture the data and then change the schema as these uncaptured/new requirements make themselves known.

edw519 18y ago
must be designed and built to meet the deadline I do the best I can Then we agree. The analysis for the app was incomplete (for whatever reason). I'm not looking to place blame, I'm just saying that a well designed data base by definition must handle the wear and tear of the app. Some of the worst crap I ever had to maintain was originally considered a success because it met its original deadline. Sigh.
- inerte 18y ago
  > I'm just saying that a well designed data base by definition must handle the wear and tear of the app Impossible. This is pure theory and has no ground on reality. Name me one database that was designed to handle Sarbanes-Oxley needs in the last decade. Business requirements change, and so does the app and the database. Tell me how you would deal with this situation in your current database designs: A few years ago, a born male person here in Brazil got his sex legally changed to female (also had a sex-change operation). So, s/he's a female for most of legal concerns, but s/he's got the genome presented on males, which means: 1) He needs to be a "female" on your employees records; 2) She needs to be a "male" on your company health insurance records; Sorry if I sounded abnoxius, I can't argue softly in English :p
  - edw519 18y ago
    Impossible. This is pure theory and has no ground on reality. I have apps still running well after 15 years that would beg to differ. You example is clearly an extreme outlier. I never said that the business requirements don't change. That would be silly. I simply said that a rigorously designed data base structure should easily handle the changes you expect in your apps. Did you build in audits? Transactions? Date effectivity? Sequentially numbered keys? Multi-part keys? I can go on and on, but you get the idea. I've made a career rewriting data base applications where the original designer failed to anticipate the simplest of new requirements. Your English is fine. And you don't sound obnoxious. I just found your "no ground on reality" a bit at odds with my opinion a millions lines of code later.
  - Harkins 18y ago
    Something a little like this happens on our elections app: politicians have a name and party, but sometimes run in an election under a different name (eg. "Robert" runs as "Bob") and party (eg. Joe Lieberman lost his primary but won in the general as an independent). And sometimes they're doing this in multiple elections at once.

by Harkins 18y ago

edw519 18y ago

must be designed and built to meet the deadline I do the best I can Then we agree. The analysis for the app was incomplete (for whatever reason). I'm not looking to place blame, I'm just saying that a well designed data base by definition must handle the wear and tear of the app. Some of the worst crap I ever had to maintain was originally considered a success because it met its original deadline. Sigh.

inerte 18y ago
> I'm just saying that a well designed data base by definition must handle the wear and tear of the app Impossible. This is pure theory and has no ground on reality. Name me one database that was designed to handle Sarbanes-Oxley needs in the last decade. Business requirements change, and so does the app and the database. Tell me how you would deal with this situation in your current database designs: A few years ago, a born male person here in Brazil got his sex legally changed to female (also had a sex-change operation). So, s/he's a female for most of legal concerns, but s/he's got the genome presented on males, which means: 1) He needs to be a "female" on your employees records; 2) She needs to be a "male" on your company health insurance records; Sorry if I sounded abnoxius, I can't argue softly in English :p
- edw519 18y ago
  Impossible. This is pure theory and has no ground on reality. I have apps still running well after 15 years that would beg to differ. You example is clearly an extreme outlier. I never said that the business requirements don't change. That would be silly. I simply said that a rigorously designed data base structure should easily handle the changes you expect in your apps. Did you build in audits? Transactions? Date effectivity? Sequentially numbered keys? Multi-part keys? I can go on and on, but you get the idea. I've made a career rewriting data base applications where the original designer failed to anticipate the simplest of new requirements. Your English is fine. And you don't sound obnoxious. I just found your "no ground on reality" a bit at odds with my opinion a millions lines of code later.
- Harkins 18y ago
  Something a little like this happens on our elections app: politicians have a name and party, but sometimes run in an election under a different name (eg. "Robert" runs as "Bob") and party (eg. Joe Lieberman lost his primary but won in the general as an independent). And sometimes they're doing this in multiple elections at once.