Array - Collection - Dictionaries?

[Isaac]

That's really funny about the article Daniel just wrote. I can definitely find the sense of humor in it and I was prepared to have a good laugh no matter what version of sides or taking sides or not taking sides that he adopted.

He pretty succinctly summarized quite a few takes on the matter. What a guy, thanks for posting the link

I suppose a lot of the things that I post are strongly influenced by what I believe I have found to be good for the overall career, which as this discussion clearly points out, is not necessarily going to agree with Microsoft's definition or naming or frankly even some of their documentation. I sometimes am apt to forget that many of the things I say ought to include the qualification, "this isn't necessarily the access textbook version of things, but this is what I think you might find most helpful if you want to make a career in the wider database area".

I admit that I am sometimes too biased and I guess all of our biases ranging from the past/history of systems, preferred platforms, preferences, careers/ambitions etc, show through sometimes.
What I probably should have said is, if anyone reading this is starting out and hoping to someday get a job on a RDBMS database development team at a company, don't talk to them about "fields in tables".
Or perhaps even more truthfully, it was my personal experience that I had to stop talking like that in order to be considered for 'database developer' at the companies I have interacted with. You may or may not have a totally different experience
But that's not what I said and I admit I was wrong.

 

[NauticalGent]

What is really interesting it wasn't THIS thread he was referring to, its this one!

 

[Isaac]

Oh dear! I would rather it be this one, as this is where ideas were much more fully developed - and includes my rare big hearted apology, of course!
Ha ha.

The only slight critique I have of his article is the final bit. Some readers, I already know, those who are predisposed to have an "Ahh - pshaw" attitude towards terminology, will take that as an insinuation that anyone who takes semantics seriously is just an argumentative crazy. Nothing could be farther from the truth. A focus on correct terms, for me anyway, has been almost a currency of success. Sometimes I get it wrong, absolutely. Sometimes I get [anything] wrong. But the strong focus on it is definitely not wrong, in fact I think the same thing in reverse: In my experience, "there are always those few people who get annoyed any time it is suggested they be diligent on terminology". I was wrong in this case, but an almost obsessive determination to put correct terminology on a pedestal is in fact a good thing....IMHO.

I don't think until this thread I had realized, myself, how strong my "terms" preferences were colored by what I think makes a person's tech career strongest, rather than the actual correct term of the platform. Sometimes you don't know yourself until other people hold a mirror! But I admit it.

After all, my tagline signature would be embarrassing if I couldn't be humble when I'd been wrong. That's why I leave it there, as flushed as it makes me sometimes, it keeps me (a little bit) honest.

 

[isladogs]

@Isaac
I had completely forgotten there was an earlier thread where you first raised the fields vs columns issue.
TBH I stayed out of the discussion until you also made the point that all number variables should be Long.

Over the years I've got bogged down in too many arcane discussions which stray far from the original point of the thread.
These days, I try to stay out of such discussions as too often they degenerate into slanging matches
Pleased to see that didn't happen here

Anyway, why not make a response explaining your viewpoint in DP's article? Unfortunately if you give a link to this thread it won't get published

 

[NauticalGent]

Anyway, why not make a response explaining your viewpoint in DP's article? Unfortunately if you give a link to this thread it won't get published

 

[Isaac]

Colin I appreciate your response and the "vote of confidence", so to speak.

I've seen people confidently assert something which is later forcefully corrected by .. others .. , and seen that first person keep digging themselves in deeper or excusing it because saying I was wrong is so hard for some of us (lol, including me) - and it was such a terrible look. I don't want to be that person, but could come perilously close if tempted or provoked by way of additional comments which give rise to any more conversation.

Your idea is a good one, and I considered it, but I've decided to just let everything lie where it lies now. DP's brief 'article' stands as a testimony to me of an argumentative side of myself I'd rather remember to keep under control in the future.

 

[NauticalGent]

DP's brief 'article' stands as a testimony to me of an argumentative side of myself I'd rather remember to keep under control in the future.

If you are saying that DP was signaling you out, I would disagree. I think he was poking everyone who took a side...

 

[The_Doc_Man]

I posted something in another thread that is relevant to this thread. See post #32 of the linked thread to see the whole article.

Why the CRUD approach is needed?

Nope. That's a control:) In Access terms, yes, But in the more generic terms within the user world, a field is pretty much anything they see on their screen that contains a data point, data element (etc etc). I'm all about the interesting (and sometimes frustrating) bridge between the...

www.access-programmers.co.uk

To keep it short here, the international SQL standard from 1999 says that (in the context of "standard SQL") a table has columns and a row has fields.
Therefore, there is some justification in "column" nomenclature, particularly if you are using Access as the FE and any active SQL engine as the BE. However, because the Access object model explicitly calls for "field" in that context, there is considerable justification in "field" nomenclature.

In an earlier part of this thread, the discussion came up regarding why one might use smaller variables in a VBA context. The answer MIGHT well be that you want the run-time system to ABSOLUTELY ASSURE that you don't try to inflict a data abomination on yourself. Strong-type languages like PL/1-G and ALGOL and PASCAL require you to describe your data as well as your procedures. VBA tends to be loose about that, and in that sense, is very forgiving for beginners. It's a blessing AND a curse.

Trust me on this: when your value has to go into a hardware-constrained usage (screen RGB color as a good example), there is ZERO forgiveness. Therefore, strong data typing is a safety feature, like having a belt AND suspenders. In that situation, if you know you are expecting exacting usage, perhaps an explicit shorter data type can be useful.

I've mentioned this before. If you don't absolutely know your project's data requirements, you have either made a mistake or you got lazy during initial planning. In one place I worked, we had to compute tolerances as well as actual measurements. Well, in software, having the right sized (and right typed) variable for the value you are computing is an example of having computed the tolerances on the value in question.