I had to stick my 2 cents in. I agree with just about everything on this thread but I think TruckmanPete just about hit the nail on the head:
I've found that most people who've never designed and built a real database application don't really understand what a database is and and how complicated they are to design and build correctly. I don't know of anyone who is even halfway proficient at building a database who has said they picked it up in just a week or two.
What's been most interesting to me is that customers usually think the hard stuff is easy and the easy stuff is hard. That alone should tell you a lot about the difficulty a beginner will have with designing a database. (That misunderstanding has also caused a couple major disagreements with customers. One thought I was cheating them because I wanted to charge $6000 for a job they thought would be high priced at $500. Needless to say, they are no longer a customer. A mutual agreement.)
Even when going from A4 to A5, there is a lot to learn because everthing but the basic relationships of sets is done differently. I made the switch back when A5v1 first came out and I'm still learning every day. And, yes, the learning process is often very frustrating. But I've also learned that I can find a solution if I just keep searching and trying.
I think one thing that people don't even consider is that, unlike a spreadsheet where you are free to enter nearly anything into any cell and it's completely up to the end user how the spreadsheet is used - and, therefore, how accurate the results will be - a good database application will restrict the user from entering bad data and assist with entering good data. However, to build all that functionality requires a lot of thought about the actual processes involved which takes a certain type of personality - one that can think in very detailed steps.
One example I've used to explain the detail required is to ask someone to explain to me how to start a car. The typical answer is something like, "Well, you get in the car, put the key in the ignition, and turn the key." The real answer is more like this:
- First determine if you are already standing up or if you are sitting down or, perhaps, still laying in bed.
- IF you are sitting down, lean forward so your weight is over your feet then push up with your leg muscles while keeping your center of weight straight above your feet until you are standing upright.
- Next, shift your weight to your right foot and put your left foot forward.
- Put your left foot down and shift your weight to that foot.
- Repeat until you've reached the hallway to the back door (checking after each step) and twist your body as you step when you reach the hallway.
- Continue stepping (moving one leg forward and shifting your weight to it) until you reach the key rack.
- Select the keys to the correct vehicle. (Some decision mechanism has to be provided here so you get the right keys.)
- Pick up the keys with your hand. (I will skip all the gory details about how to do that.)
- Move your left hand to the door knob on your left then grab the doorknob and twist it. (Allow for checking to see if this knob has a lever type handle rather than the more conventional knob.)
...... etc., etc., etc.
Of course, if you are simply building a small database that you will be the only one to use or you don't mind spending weeks training someone else to use it, you can just build some tables and maybe a couple sets and enter the data into the default browses or default forms. However, as soon as you want someone else to use it, I guarantee there will be problems and a lot of bad data before they learn to do it right.
Therein lies the power of a database. A well written application can overcome most of the "bad data" issues and make data entry fast, easy, and accurate. Trying to accomplish the same thing in a spreadsheet or, worse yet a word processor, is nearly impossible.
Unfortunately, learning to harness all that power is not so fast and easy.
My own experience is that databases are complex programs with a very steep learning curve early on. A database is not a word processing program. It isn't even a spreadsheet program. Just by the nature of what a database tries to do, programming, whether you use a genie,wizard or scripts is something that will take time and thought.
What's been most interesting to me is that customers usually think the hard stuff is easy and the easy stuff is hard. That alone should tell you a lot about the difficulty a beginner will have with designing a database. (That misunderstanding has also caused a couple major disagreements with customers. One thought I was cheating them because I wanted to charge $6000 for a job they thought would be high priced at $500. Needless to say, they are no longer a customer. A mutual agreement.)
Even when going from A4 to A5, there is a lot to learn because everthing but the basic relationships of sets is done differently. I made the switch back when A5v1 first came out and I'm still learning every day. And, yes, the learning process is often very frustrating. But I've also learned that I can find a solution if I just keep searching and trying.
I think one thing that people don't even consider is that, unlike a spreadsheet where you are free to enter nearly anything into any cell and it's completely up to the end user how the spreadsheet is used - and, therefore, how accurate the results will be - a good database application will restrict the user from entering bad data and assist with entering good data. However, to build all that functionality requires a lot of thought about the actual processes involved which takes a certain type of personality - one that can think in very detailed steps.
One example I've used to explain the detail required is to ask someone to explain to me how to start a car. The typical answer is something like, "Well, you get in the car, put the key in the ignition, and turn the key." The real answer is more like this:
- First determine if you are already standing up or if you are sitting down or, perhaps, still laying in bed.
- IF you are sitting down, lean forward so your weight is over your feet then push up with your leg muscles while keeping your center of weight straight above your feet until you are standing upright.
- Next, shift your weight to your right foot and put your left foot forward.
- Put your left foot down and shift your weight to that foot.
- Repeat until you've reached the hallway to the back door (checking after each step) and twist your body as you step when you reach the hallway.
- Continue stepping (moving one leg forward and shifting your weight to it) until you reach the key rack.
- Select the keys to the correct vehicle. (Some decision mechanism has to be provided here so you get the right keys.)
- Pick up the keys with your hand. (I will skip all the gory details about how to do that.)
- Move your left hand to the door knob on your left then grab the doorknob and twist it. (Allow for checking to see if this knob has a lever type handle rather than the more conventional knob.)
...... etc., etc., etc.
Of course, if you are simply building a small database that you will be the only one to use or you don't mind spending weeks training someone else to use it, you can just build some tables and maybe a couple sets and enter the data into the default browses or default forms. However, as soon as you want someone else to use it, I guarantee there will be problems and a lot of bad data before they learn to do it right.
Therein lies the power of a database. A well written application can overcome most of the "bad data" issues and make data entry fast, easy, and accurate. Trying to accomplish the same thing in a spreadsheet or, worse yet a word processor, is nearly impossible.
Unfortunately, learning to harness all that power is not so fast and easy.
Comment