- Local time
- Today, 15:37
- Joined
- Feb 28, 2001
- Messages
- 27,231
@John Sh - though Galaxiom hid your response to me, I am a moderator and thus can see it.
If you bother to more closely read my response (to which you appeared to have an objection), I was actually condoning the fine art of "making it work" - under pressure, since I am also an ex-spurt. The last part of my last paragraph was about what happens when you have a less than ideal database and/or situation as your starting point. My overall response was two-fold.
First, doing it "right" is important since you have to answer this question: If you haven't enough time to get it right the first time, how will you EVER find time to fix it? Short answer? You can't. I've tried but that pesky clock keeps on ticking.
Second, software engineering is the art of the possible, not the art of the elegant. I have no doubt that I have engineered dozens of ugly short-cuts many times. You do what you have to do within the time and resources you have. I get it and don't disagree with it. In the end analysis, I am as much a pragmatist as I am a theorist.
You complain about our advice but you need to recognize this fact: A relational database is written based on hard (and provable) mathematical theorems having to do with properties of sets. (Database tables, each full of records, are SETS in this context. Why do you think we talk about recordsets?) Based on these hard set theory rules, one can derive or extract (however you wish to say it) certain basic design rules that help to make your work more efficient, more effective, and generally easier. However, that "extracted rule" isn't "extracted out of our keisters" or "extracted from thin air." It is based on study and experience.
From time to time, experienced members will talk about optimization and normalization and all those other yucky things that seem to get in the way of just getting in there and DOING it. We do this because, in a limited sense, we are like parents who really don't want our kids to make the same mistakes we have made, to your eventual displeasure and detriment. You see, we have something called "experience." You DO know the true meaning of experience, don't you? It is the ability to recognize your mistakes when you make them again.
I learned a useful lesson a long time ago. When you don't know what to do, that does not prevent you from knowing what NOT to do. When programming or when playing bridge or when living life, the same rules apply: When in doubt, avoid doing something that is clearly wrong. Well, we often tell you what is clearly wrong. It isn't meant to vex you, but rather is meant to help you by eliminating bad paths. You still get to choose from among a LOT of other paths.
When you tell us to "LOOSEN UP" I merely reply, "Don't tell me. Tell the Access program to loosen up. But don't be disappointed if it doesn't, since you are railing against the insistent forces of mathematics and set theory. Not to mention talking to an inanimate object." We are not all one-eyed when it comes to proper structure. It is just that many of us have, in the past, pissed into the wind and gotten back a face full.
In closing, your response triggered another of our long-term moderators. He felt your response was disrespectful. I am answering you in public but trying to be respectful in this answer. Please look at the menu bar at the bottom of the page and note the "Terms and Rules" section. You would find that repeated disrespect of other members is one of the "unforgivable curses" on the forum.
If you bother to more closely read my response (to which you appeared to have an objection), I was actually condoning the fine art of "making it work" - under pressure, since I am also an ex-spurt. The last part of my last paragraph was about what happens when you have a less than ideal database and/or situation as your starting point. My overall response was two-fold.
First, doing it "right" is important since you have to answer this question: If you haven't enough time to get it right the first time, how will you EVER find time to fix it? Short answer? You can't. I've tried but that pesky clock keeps on ticking.
Second, software engineering is the art of the possible, not the art of the elegant. I have no doubt that I have engineered dozens of ugly short-cuts many times. You do what you have to do within the time and resources you have. I get it and don't disagree with it. In the end analysis, I am as much a pragmatist as I am a theorist.
You complain about our advice but you need to recognize this fact: A relational database is written based on hard (and provable) mathematical theorems having to do with properties of sets. (Database tables, each full of records, are SETS in this context. Why do you think we talk about recordsets?) Based on these hard set theory rules, one can derive or extract (however you wish to say it) certain basic design rules that help to make your work more efficient, more effective, and generally easier. However, that "extracted rule" isn't "extracted out of our keisters" or "extracted from thin air." It is based on study and experience.
From time to time, experienced members will talk about optimization and normalization and all those other yucky things that seem to get in the way of just getting in there and DOING it. We do this because, in a limited sense, we are like parents who really don't want our kids to make the same mistakes we have made, to your eventual displeasure and detriment. You see, we have something called "experience." You DO know the true meaning of experience, don't you? It is the ability to recognize your mistakes when you make them again.
I learned a useful lesson a long time ago. When you don't know what to do, that does not prevent you from knowing what NOT to do. When programming or when playing bridge or when living life, the same rules apply: When in doubt, avoid doing something that is clearly wrong. Well, we often tell you what is clearly wrong. It isn't meant to vex you, but rather is meant to help you by eliminating bad paths. You still get to choose from among a LOT of other paths.
When you tell us to "LOOSEN UP" I merely reply, "Don't tell me. Tell the Access program to loosen up. But don't be disappointed if it doesn't, since you are railing against the insistent forces of mathematics and set theory. Not to mention talking to an inanimate object." We are not all one-eyed when it comes to proper structure. It is just that many of us have, in the past, pissed into the wind and gotten back a face full.
In closing, your response triggered another of our long-term moderators. He felt your response was disrespectful. I am answering you in public but trying to be respectful in this answer. Please look at the menu bar at the bottom of the page and note the "Terms and Rules" section. You would find that repeated disrespect of other members is one of the "unforgivable curses" on the forum.
