Jeff said:
Like Duane, I've noticed that some of the
words you use could be interpreted as negative, pejorative, denigrating, ...
That does bother me, I do give a damn.
To tell the truth, I always post will a cheery grin on my face; really,
I could put a <g> on the end of every sentence because I have so much
fun. Why do anything if you don't enjoy it? I even take character
assassination of the chin (there I go again <g>). Am I making fun of
people? Sometimes but I intend no malice; I just was them to reflect on
what they've written.
I find it hard to give 'negative' feedback, without getting people's
backs up, of the kind, "This would appear to be a misstatement
<devastating proof follows>", "I couldn't disagree more <opinion glean
from the wider SQL community follows>". Perhaps my whole approach is
wrong but I feel it adds value to 'challenge' someone who has
inadvertently said something that can be falsified or expressed an
opinion which does not reflect SQL DBMS 'best practice'. I just want
people to reflect on the answers and ask themselves, "Was that the best
I could have done?"
And that applies to the respondent - more so, actually - as well as the
OP. I know there are some people who think this is a Q & A forum i.e. a
number of answers are given directly to the OP for them to pick one. I
prefer 'peer review' e.g. "Dear OP, I think this answer is better than
this one because <devastating proof, citation to article, etc>."
Sometimes this leads to a discussion and *I* learn something new,
win:win.
It can be difficult for someone without those magic three letters after
their name to be heard around here (especially so in the
microsoft.private.* newsgroups <g>). Take, for example, the last
incident that got me into trouble (entering dodgy ground here, I know).
Many years ago (and before my time) a respected regular (I'm being
vague because this is not about personalities), whose posts are almost
without exception of the very highest quality, wrote an article about a
fundamental area of Jet 4.0 functionality from an inexplicably biased
position (IMO), including a number of apparent inaccuracies and
concluding that the whole 'feature' be avoided. To this day, the author
and many others continue to cite this article, sometimes even at the
mere mention of the area of functionality, and it seen to have a
significant effect on the Access community. For me, this area of
functionality is vital and the workarounds either appear kludges and
sometimes dangerous (some say illegal - certainly would horrify an
auditor, if they knew). I've spend a lot of time investigating the Jet
implementation of this functionality, have even turned up a few
'oddities' (assumed bugs) myself, and feel in a position to not only
present a different view but a more balanced one (IMO).
My attempts - I won't list them here but getting up people's noses to
provoke a response is one I used to employ a lot - to change the
situation has had had some effect but not the desired outcome: for the
author to review the article, remove the inaccuracies (or back them up)
and, ideally, present a more balanced view.
So, Jeff, while I have your ear, help me out here. My unprofessional
approach (I admit as much) has not worked. What would the professional
do in such a situation to influence (or generate) the debate? If I
started a new thread covering just one point raised in the article,
would you be interested in contributing to a discussion?
The words folks use
typically are interpreted by the folks who read them
The above rant isn't too far OT, I hope. I agree that the language
people use here is very important. I'm I too bold in thinking I can
change the world for the better, in some small way?
For example, I tend to cringe a little when someone says, "I have made
a Relationship enforcing referential integrity, linking the child table
to the parent." The SQL standards and most of the SQL literature
(including author's posts in newsgroups) use the term REFERENCES
('child'), hence REFERENCED ('parent'). Using these terms encourages a
correct mental model, whereas 'parent/child', 'linking' and even
'relationship' can lead people astray (not just my opinion) even if
they are universally understood. And putting SQL keywords in uppercase
means I can differentiate between syntax (PRIMARY KEY) and concepts
(primary key e.g. enforced in a 'history' table using a table-level
CHECK constraint) but does the reader think I'm shouting?
I think it a shame when people in the Access community use language
that potentially alienates them. I'm on dodgy ground again but I'm
still trying to some up with an alternative to the offensive term
'ghetto' (cul-de-sac? suburb? clique?) to try to get people to think in
terms of *not* alienating themselves from a wider community. If
(almost) everyone else calls them 'lookup tables' then why not embrace
the term? I get that 'lookup fields' are pejorative around here: so
change *their* name, adopt a new convention e.g. called them FFs, a
contraction of 'f***up fields' (yes, extreme language - sorry).
There is a lot of 'gray'. Do the terms 'column' and 'row' encourage a
spreadsheet mindset? Personally, I think there is value in using
column/row where there is no implied order (i.e. a set) and
field/record where there is (e.g. a recordset that has a MoveFirst
method, an EOF property, etc).
My overall aim is to be inclusive. For example, when creating a
database, you (whoever) may never use ADO and your front end may
exclusively use DAO but is it really 'professional' to code Query
objects (VIEWs and PROCs) to give wrong results, validation rules to
fail, etc when someone accesses the backend via ADO? Language can
contribute to exclusion (note even as a limey I often US English e.g.
'gray' rather than 'grey')...
Actually, this has been quite a cathartic post. Perhaps I should face
the fact that my 'noise to signal ratio' is way off and I'm not adding
(enough) value.
Jamie.
PS I hope you remembered to add a notional <g> to the end of each
sentence ;-)
--
Last time I tried