Why the CRUD approach is needed?

[Isaac]

You're talking about DAO now, which isn't what we were discussing, but I'll agree with the cantankerousness part, as that took some serious reaching!

 

[Galaxiom]

Technically "( )" are called "parentheses" in text but "brackets" in mathematics.

 

[Galaxiom]

I would never tell a user "Let's add a Control to the screen" - I would say "Let's add a Field to the screen".

You are part of the problem then.

 

[Isaac]

When I was in a cubicle next door to our resident C#.net developer, I remember him showing me some stuff and seeing a heck of a lot of them, whatever they are

 

[Isaac]

You are part of the problem then.

Well hello again, @Galaxiom. I would disagree with you on that - there is a translation of sorts that has always been needed between the business and the tech groups. In my experience, I can take the rather petty approach of demanding that end-users speak my language, or I can accept that will never happen and meet them where they are at. In an entire lifetime in the adult working world, in the USA at least, at the companies I have worked at, many of which had massive projects going at any given time, the typical users, business analysts, project managers, and corporate project sponsors insisted on using "fields on a screen". Thus, I adapted to their way of thinking while meeting with them and developing requirements.

I do not try to talk 100% tech with an end user.
Do you?

Actually, don't bother to respond to that. I sense you do not wish the same conciliatory end to this matter as I, and am quite finished with this argument, as was made plain on the other thread.

I wish you a more relaxed, pleasant and productive remaining week,
Isaac

 

[The_Doc_Man]

You're talking about DAO now, which isn't what we were discussing, but I'll agree with the cantankerousness part, as that took some serious reaching!

I'm talking about the basic structure of the database. It is true that a DAO recordset has a "Fields" collection, but the table has that collection even when it is not the target of an explicit DAO Recordset. In fact, the DAO recordset probably copies/references/otherwise gets it from the TableDef.

 

[The_Doc_Man]

Having now looked it up, this is what the standards document says. (Taken from: ANSI/ISO/IEC International Standard (IS) Database Language SQL—Part 2: Foundation (SQL/Foundation) - 1999.)

From paragraph 4.15 (Columns, fields, and attributes)

"The terms column, field, and attribute refer to structural components of tables, row types, and structured types, respectively, in analogous fashion. As the structure of a table consists of one or more columns, so does the structure of a row type consist of one or more fields and that of a structured type one or more attributes."

According to another part of this same standards document, it is permissible to use the word "field" in conjunction with the conventional elements of a date/time value, such as "hours field" or "days field" - since they allow "sub-fields" to be defined and a sub-field is also a field.

Also from that standards document: "A row type is a sequence of (<field name> <data type>) pairs, called fields. It is described by a row type descriptor. A row type descriptor consists of the field descriptor of every field of the row type."

Therefore, there is some basic agreement in the SQL standards document that the term "Column" can indeed apply to something that, once you reach the individual row level, becomes a "Field." This DOES NOT single out DAO in this context.

Common usage in Access always calls that "thing" a field to avoid confusion with the nomenclature of Excel, to which nearly EVERYTHING is a book/sheet/row/column situation. Recall our previous discussion that if all you have is a hammer, everything looks like a nail. Well, if all you have is Excel, everything looks like rows and columns.

 

[Galaxiom]

Common usage in Access always calls that "thing" a field to avoid confusion with the nomenclature of Excel, to which nearly EVERYTHING is a book/sheet/row/column situation.

The "cell" is also an important concept in Excel.

 

[Galaxiom]

"The terms column, field, and attribute refer to structural components of tables, row types, and structured types, respectively, in analogous fashion.

I work in Access, SQL Server and Universe so I need to use all these terms and a lot of others. Little wonder I am pedantic about nomenclature.

Universe is a non-1NF database having "attributes" with "multivalues" which can have "subvalues". Its native language (TCL) uses a "sentence" in the structure:

LIST tablename attribute1 attribute2 WITH attribute3 = whatever

String delimiters are optional if there is no ambiguity. And yes, no commas.

Tables are actually "files" with a "VOCabulary" entry that presents it as table name.

Technically the attributes for TCL are F1 F2 F3 etc (defined by system level descriptors) but a "Dictionary" of descriptors defines alternative names and formats as well as "Associations" between the multivalues of attributes that act like a Relationship between multivalue attributes. The descriptor defines if the output is single or multivalue. Without a descriptor, all values are text.

An "I" descriptor can do complex manipulations on the values and lookups from other tables. A descriptor can call a UNIVERSE BASIC subroutine (function). Generally I-descriptors are used to do most of the complex work.

I-descriptors can Raise or Lower a value, multivalue or subvalue to the next level, eg raising a subvalue to present it as a multivalue or top level value.

There are also descriptors for Verb (keyword definitions), Adverb, Phrase, Sentence and Paragraph.

Dynamic descriptors can also be EVALuated inline and the format of the values and their layout in the results altered. Associations can be defined inline.

A sentence can be written USING a different dictionary.

This sentence will create a "Select List" that applies to subsequent LIST command.

SELECT tablename attribute1 attribute2 WITH attribute3 = whatever

It also supports a flavour of SQL with "dynamic normalization" that brings out the multivalues as "virtual tables". Only Dictionary descriptors are supported in SQL but all the inline TCL functionality is also supported.

Depending on how it is being addressed, the query criteria key words are WHERE and WHEN. Both WHERE and WHEN are used in the same query. WHERE refers to the whole set of multivalues while WHEN refers to individual multivalues within the WHERE criteria.

"Select Lists" can be written to and applied to SQL.

SELECT descriptor1, descriptor2 TO SLIST  'listname' FROM tablename

SELECT attribute1, atribute2 FROM tablename SLIST  'listname'

A table can UNNEST on a multivalue or Association to repeat the single values presenting all the multivalues as full records.

The table to column separators are dots. The table to dynamically normalized table separator is an underscore. Meanwhile identifiers (tablenames and attribute/column descriptors) can include both underscores and dots without the need for delimiters. They are also case sensitive.

The ODBC interface converts all dots in identifiers to underscores.

So next time you are thinking Access or T-SQL syntax is complicated, spare me a thought.

 

[MajP]

@Isaac not saying you are wrong, and I may be an anomaly, but in my personal experience everything below is about 180 out.

Calling a Column a Field makes no sense at all IMO, for several reasons:

• It's not a field, it's a column
• RDBMS professionals (non-Access) call it a Column
• Field is too broad, field can mean any device, real or imaginary, that contains just about anything
• Field is usually used by non-tech users to refer to anything they see on the screen

At first I assumed this was some difference in British vs American English. As we know these Brits here do not always speak properly and have some very silly language differences (lifts, and the Tube, and Chips for French Fries). So I checked your profile, and clearly you are not British.
In my experience only time it is referred to as a column is in display but in database design its a field. And it is the non db people, who work in Excel that are the ones calling everything a column.

I personally would never say I join two columns together, or call it a Primary and Foreign column, or it is a required column, etc.

 

[NauticalGent]

As we know these Brits here do not always speak properly and have some very silly language differences...

Oh, you done did it now...

 

[Galaxiom]

Chips for French Fries

Chips are not French Fries. Quite different. Chips are thicker.

 

[GPGeorge]

Chips are not French Fries. Quite different. Chips are thicker.

So they come in appealing flavors, like "Sour Cream and Onion" or "BBQ"?

 

[isladogs]

Often curry sauce or Mayo

 

[Minty]

These are Crisps:

These are French Fries:

These are Chips!:

Hence this is Fish & Chips:

No discussion or arguments required obviously.

 

[jdraw]

Hmmm? Saratoga

 

[NauticalGent]

 

[Isaac]

@Isaac not saying you are wrong, and I may be an anomaly, but in my personal experience everything below is about 180 out.

At first I assumed this was some difference in British vs American English. As we know these Brits here do not always speak properly and have some very silly language differences (lifts, and the Tube, and Chips for French Fries). So I checked your profile, and clearly you are not British.
In my experience only time it is referred to as a column is in display but in database design its a field. And it is the non db people, who work in Excel that are the ones calling everything a column.

I personally would never say I join two columns together, or call it a Primary and Foreign column, or it is a required column, etc.

Thanks for the thoughtful reply. I'm comfortable just chalking some of these diverging viewpoints up to personal experiences and moving on.

I do see your point, it's just definitely different in my experience. I've worked on a variety of SQL Server teams (talking about US companies, as you mention), ranging from major banks (Wells), insurance companies, healthcare companies, etc., and a few SQL dev groups that were combined with the Oracle guys, and for some odd reason, my experience is the opposite of yours (I assume that's what 180 out means??).

I would never not say joining two tables "on [a certain] column". I won't say I've NEVER heard "on __ field", it's happened at least a few times, it's just not how most of them talk that I have been around.
Almost everyone I have heard at the professional level in RDBMS teams (sql server and oracle), talks about columns as columns, including joining on columns. A few well-known people on places like sql server central even put it in their signatures (!) to encourage newcomers to begin learning how to think in terms of acting on Columns. Some of them even make kind of a big deal out of it.

For example. I google "sql server join tables". From the Results page, you see 99.9% reference to "Columns". I do a Ctrl+F in Chrome for "Field", and I only see TWO references on the whole results page. Those two results are from "webpagesolutions.com" and "tutorialssolution.com".....

However, I can respect your approach as it's based on your experiences, we probably each subconsciously have steered our career experiences in 100 different tiny ways where for whatever reason, I ended up being exposed to it as mostly one thing, you as another.

But remember, I have already--in a different thread I think? losing track now--acknowledged that I was wrong about the Access term. It is true that Microsoft insists on calling them Fields in Access and that is what it is, to the extent that I failed to give credit to that in my earliest posts, I was wrong. And to be clear, in this post, I am only talking about the "bigger picture" RDBMS terminology. So if you, in your post, were only referring to Access, then yes, I was wrong because in Access they're called fields, no matter what I think of it.

 

[Leroyer2024]

Chips are thicker.

 

[DickyP]

Create --> POST
Read --> GET
Update -->PUT
Delete --> DELETE

Two terms for essentially the same operations. In the database environment, the terms, Create, Read, Update, Delete are used. In the web environment, the terms POST, GET, PUT and DELETE are used.

I can honestly say that in 40+ years of computing from back in the days of coding sheets and punch cards I have only ever heard/used CRUD. Don't you just hate it when people re-invent the wheel. Especially when they tell you that square wheels are now the thing.