3 ms·

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

by 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 inerte 18y ago

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.