Drew Jensen a écrit :
Hi Drew,
If I may ask a few philosophical questions and get some of your
collective wisdom., thank you.
You may ;-) although I doubt that my response will be very philosophical
in return :-))
As I say, verbose column names indeed. But when you use the form
wizard against that table you get nice meaningful labels. Same for
reports. None of that, run the wizard now go back and select each
label and change the string from, for example, "DateClosed" to "Date
case closed" - no need, it's much more likely the form is 'as desired'
when the wizard is finished then not.
True, and it does save time on form building, but on queries using SQL
it's one PITA having to type in so much, with the risk of mistyping or
having to put everything in quotes (OK, most CLI shells have tab
completion if the db supports that feature, so maybe I'm being a bit
excessive).
A few days ago Villeroy said that he doesn't use the GUI query
designer - he prefers to type in the SQL commands directly - for him
then those column names would be a pain in the rump IMO. But again, I
think not using the GUI tools must be looked at as the great exception
with regards to the target users. The average Base user is going to
use the GUI query designer, the same for the report creation tools. In
report builder, drag that column onto the report and there you go - no
extra edit to the label is needed.
Yes, I tend to agree with him now, although that's because I've had to
make do with Base's shortcomings, to the point where I do nearly
everything in SQL. If I look back to when I was a complete beginner,
I'll willingly admit that is was nice to have GUI features that did all
that ground work for you. This was, and still is the case, with db tools
like FMPro, or Lotus Approach or even the older Borland tools (I can't
speak for Access, having never used it to build anything).
Also notice that there is no FK relation for the State field. Once
again a decision based on the target user or more precisely the target
use. In this situation it makes sense to me to expect that this will
be a relatively small number of values ( remembering that the target
user is most likely building this for personal or personal work group
use). So that the best way to handle data validation is simply to use
a combo box on any input form with a data source command of "SELECT
"State", "State" FROM "Therapist", offering quick entry of redundant
data, easily added new values and consistent case with check
constraint. Another way to look at that is that this use of the combo
box with a self referencing select statement should be similar to the
data input experience of most spread sheet users.
But - do any of you think that is a bad thing for a tutorial to show -
should a tutorial instead stick to look up tables for this type of thing?
I must admit to being a bit of a stickler here - I much prefer to use
lookup lists, but then that is how I learnt from my elders :-) Keep
everything nice and separate, although I can see your point, especially
where the number of distinct values is small, but having said that, I've
created lookup lists for stuff that only had 5 different possible
values, so I'm probably too stuck in my own mould to change now. I've
tried using ENUM fields in the past, but here again, it just doesn't cut
the mustard when you've got a lot of stuff to list, or when you've got
to update the lists on a frequent basis.
Well, so much for my ramblings, I'm not convinced that they'll have
brought you any further along your road :-)
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
