Why the CRUD approach is needed? (1 Viewer)

[prabha_friend]

Can't we use everything using the Oldies itself (GET, POST, PUT, DELETE)

If something is invented (or Introduced) there must be a lack in the previous and are advantages in the latter? What are they? Need to understand. Please share your knowledge.

With Hope,
Prabhakaran

 

[GPGeorge]

What is this "something" to which you refer? Why are you concerned about this issue?

 

[prabha_friend]

'Something' is CRUD and the oldies are GET, POST, PUT, DELETE

 

[GPGeorge]

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.

It's sort of like speaking more than one language. I speak English and a little Spanish, for example. I imagine you also speak more than one language. We use one language in some contexts and another language in other contexts. That does NOT imply that either language lacks in any way or has advantages in any way. Only that the context determines which is appropriate.

It's the same with these terms; context determines which is appropriate.

 

[Mike Krailo]

CRUD conveniently spells a word and PGPD does not.

 

[The_Doc_Man]

Well, in some operating systems the CRUD is actually DREW (Delete, Read, Execute, Write) except they then scramble it to RWED. You are in this case talking about privileges or permitted actions or permissions. The general rule is that if you invent an operating system or complex program and have to implement some kind of flag-oriented system to define some controllable options, you get to name the options. When you run across a new combination such as the one you singled out, you have to realize you crossed a logical boundary to get there. Think of it as crossing a border into a different country that doesn't speak the same language as the one you just left. Would you expect the natives to change languages just to suit you?

If something is invented (or Introduced) there must be a lack in the previous and are advantages in the latter? What are they? Need to understand. Please share your knowledge.

The thing you are missing here is that names are defined to identify actions relevant to the specific product - whether it is an operating system, a database system, a batch processing system, or an address book. If there is some difference between the basic options in an operating system vs. a web design system, the names WILL change - and the acronyms will have to change with them. Perhaps the names are made different to help you, to jog your memory to remind you that you are in a new environment.

If there is a lack in some other system, it may simply be that the basic actions in one system do not map exactly to the actions in another system. That is because of that old, rarely stated, but absolutely correct rule: "One size DOES NOT fit all."

 

[GPGeorge]

Spoiler: etc

Well, in some operating systems the CRUD is actually DREW (Delete, Read, Execute, Write) except they then scramble it to RWED. You are in this case talking about privileges or permitted actions or permissions. The general rule is that if you invent an operating system or complex program and have to implement some kind of flag-oriented system to define some controllable options, you get to name the options. When you run across a new combination such as the one you singled out, you have to realize you crossed a logical boundary to get there. Think of it as crossing a border into a different country that doesn't speak the same language as the one you just left. Would you expect the natives to change languages just to suit you?



The thing you are missing here is that names are defined to identify actions relevant to the specific product - whether it is an operating system, a database system, a batch processing system, or an address book. If there is some difference between the basic options in an operating system vs. a web design system, the names WILL change - and the acronyms will have to change with them. Perhaps the names are made different to help you, to jog your memory to remind you that you are in a new environment.

If there is a lack in some other system, it may simply be that the basic actions in one system do not map exactly to the actions in another system. That is because of that old, rarely stated, but absolutely correct rule: "One size DOES NOT fit all."

All true, but I would not consider that a "lack" in the other system. As you indicate, the terms are, instead, "appropriate" to the system. The fact that systems are different and may support different operations doesn't make one "better" than the other.

I kind of want to nitpick the border-crossing analogy, although it's very good at bringing out the point. People can, and do, speak multiple languages regardless of which side of a border they happen to be on at the moment. The problem only comes when people expect not to have to adapt when they do cross into an environment where the majority of people speak only one other language. The fact that we can discuss the topic here, in fact, means that we are "multi-lingual" with regard to systems terminology. I'm reminded of the old stereotype of the traveler who insists that if they shout loud enough, everyone will understand English.

 

[The_Doc_Man]

People can, and do, speak multiple languages regardless of which side of a border they happen to be on at the moment. The problem only comes when people expect not to have to adapt when they do cross into an environment where the majority of people speak only one other language.

Ah, but George... you got my point exactly. You should EXPECT the change and therefore learn the lingo ahead of time. Adaptation is how Man evolves - and how a man evolves.

 

[GPGeorge]

Ah, but George... you got my point exactly. You should EXPECT the change and therefore learn the lingo ahead of time. Adaptation is how Man evolves - and how a man evolves.

Unless you can shout loud enough. That is equivalent, IMO, to insisting that the familiar terms (e.g. GET, PUT, POST, DELETE or CREATE, READ, UPDATE, DELETE, etc.) are the "right" terms and everything else is a deviation from the norm. And unfortunately, there is plenty of that in the world, too.

There is also the problem of enclaves within a country, or state, or county, where the residents refuse to learn the local lingo of the larger community around them for one reason or another.

I know, I'm branching way out from the original question, so I'll stop here.

 

[Pat Hartman]

Can't we use everything using the Oldies itself (GET, POST, PUT, DELETE)

You must be very young. It is CRUD that is the "oldie" terminology, NOT Get, Post, Put, Delete. CRUD has been around since the advent of relational databases in the 70's probably well before you were born. the other terms, come to us from the advent of the web which is much younger than RDBMS'.

 

[Isaac]

George makes a good point about the often resistance to using the terms of one's surroundings.

I think human nature makes it so it can actually be difficult, sometimes, to stop and think accurately about whether or not one's preference for a term (or resistance to a term) is actually useful/appropriate, or whether it's just a preference based on a 1000 tiny opinions and experiences in one's brain that make one want to cling to one or reject the other.

I think humbly of my own preferences and how they may or may not be all that useful.
- Disliking when people use the term "worksheet" to refer to an Excel workbook file (but then again, Windows doesn't help by actually using "worksheet" in File Explorer!)
- Disliking when people use the term "field" to mean a database column (then again, Microsoft doesn't help the situation by going back and forth itself)
- The debate over "bracket" vs. "parenthesis", etc. etc and the list goes on.

On the other hand, I believe it's very important to STRIVE to use the best term, because technical platforms are all about those terms and those terms help define things, without which there is not enough specificity to really communicate. But sometimes we can get perhaps a bit obsessed about it. (me included)

 

[The_Doc_Man]

On the other hand, I believe it's very important to STRIVE to use the best term, because technical platforms are all about those terms and those terms help define things, without which there is not enough specificity to really communicate. But sometimes we can get perhaps a bit obsessed about it. (me included)

Got to agree with you, Isaac... The desire to use older, common nomenclature runs directly counter to the need for precision in ANY field of science.
For instance, if you have a problem with your phalanges, to describe the problem to your doctor, you need to talk about the next nearest area, which would be metacarpal or metatarsal (hand or foot) joints - 'cause phalanges are your fingers and toes - opposite ends of the body.

If you have radiation exposure, it would be nice for the doctor to know if it was alpha, beta, or gamma. Alpha, you treat like 1st-degree burn. Beta, maybe like 2nd degree burn. Gamma? You need to get chemical treatments to absorb and flush the secondary irradiation to your cells. And you probably need to schedule a visit to an oncologist.

Therefore, I agree that you should use the best, most accurate term to describe things if you need to communicate something.

 

[isladogs]

Now I want to nitpick about the relative effects of radiation on the body.
Whilst alpha has a very limited range and won't get beyond the surface layer unless ingested, it is slow moving and heavy so has a much greater effect on the tissue it is in contact with than beta or gamma. By contrast, gamma is fast moving, has no mass and largely passes through materials with minimal interaction.
Doesn't mean I want to have lengthy exposure to gamma but the treatment analogy you describe is misleading in my opinion.

 

[CJ_London]

- The debate over "bracket" vs. "parenthesis", etc. etc and the list goes on.

I go for bracket - can't spell pratenethis parentehis

 

[isladogs]

On the other hand, braces do 'hold up' better than curly brackets

 

[jdraw]

Jeez, maybe another dialect for Google Translate, or a new seed term (based on the user's age) for some version of ChatGPT.

I agree with Pat on this, CRUD was very common terminology in late '70s especially for followers of James Martin (books and IEW/KnowledgeWare) and database gurus of the day (Chen).

 

[Pat Hartman]

Parentheses is the pre-computer term for the characters = () . The use of the word bracket came much later. In the mainframe world, we never called parentheses brackets.

For relational databases we have -- Table-Tuple-Column but everybody says Row. No one uses tuple. You only see that term in college papers.
For flat files we have -- File-Record-Field

Field is more generic since we use both tables and files. But I can't argue that Column is more precise.

In COBOL, arrays were called Tables and they were much easier to use because in what you all call multi-dimentional arrays, in COBOL, you could refer to the "row" as well as the individual pieces of data which is very convenient. Kinda' like a custom data type. That's probably the only structural element from COBOL that I miss.

 

[Isaac]

The only thing I shall protest is the Field vs. Column thing.

To me a column is a column is a column, it is nothing else.
A field can be a variety of things, but in Access development, I try to teach newbies: "A field is on a form. A column is in a table".

Another place this is especially relevant is when talking to business partners / requestors. They always want "another field".
All that [should] mean to them [anyone] is, "I want to see something on my screen".

Definitely in RDBMS communities beyond Access, it's practically a requirement that one begin thinking in terms of acting on Columns.
And specifically as opposed to 'fields', which, while could mean anything, is too often thought of as one "cell" in a "grid", none of which is good thinking for database stuff.

I actually do use the term Relation (it should be "Relation-Tuple-Column") on a regular basis, for example the other day I was evangelizing my preferred SQL formatting style to a colleague and the only truly correct way to say it was:

I believe every thing in the FROM clause that produces a relation should be on its own separate, indented, line.

This is the most 'proper' way for ones' eyes to interpret the results, IMO.

From

    sometable s
    inner join anothertable a on s.col=a.col

All the other stuff people come up with just confuses the simple truth that each of those lines I put above equates to another relation in the algebra tree.

 

[Pat Hartman]

A field is on a form

Nope. That's a control

 

[The_Doc_Man]

Now I want to nitpick about the relative effects of radiation on the body.
Whilst alpha has a very limited range and won't get beyond the surface layer unless ingested, it is slow moving and heavy so has a much greater effect on the tissue it is in contact with than beta or gamma. By contrast, gamma is fast moving, has no mass and largely passes through materials with minimal interaction.
Doesn't mean I want to have lengthy exposure to gamma but the treatment analogy you describe is misleading in my opinion.

To be honest, it HAS been a while - but the crap we used in the Nuclear Chemistry lab was, at the time, discussed in the way I did. If you have enough irradiation to see a skin effect from any of them, then Alpha did the shallowest while Gamma did the deepest, with Beta in between. Being "cooked" by ANY of them would be a bad thing.