Talk:Create, read, update and delete

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Untitled talk[edit]

Note, I made the cleanup and NPOV-section edit, but I wasn't logged in. Insomniacity 23:23, 25 Jun 2005 (UTC)

New Jersey musician[edit]

Is there any truth in this odd section about a supposed NJ musician? Insomniacity 23:23, 25 Jun 2005 (UTC)

I am he. I added the entry myself; the neutrality issue notwithstanding, you may rest assured that this is not any type of slander of another person's character. -Crud.

Disambiguation[edit]

I split out the section on the game to Crud_(game), then moved the rest here. RickScott 20:41, 13 July 2005 (UTC)[reply]

While researching what this acronym means, I found a reference to a publication that said it stood for Create, and Read Until Deletion which is an algorithm for the management of memory shared by concurrent processes -- which which does not sound like "persistent storage" at all to me. Apparently it's in a paper by professors Wim H. Hesselink and Jan Friso Groote from the Eindhoven University of Technology in the Netherlands. A copy of the paper can be retrieved from here.

Unfortunately I don't feel qualified nor do I have the time to write about an article on the alternative meanin, but I think -- at a minimum -- it should be noted somewhere, perhaps on a disambiguation page (also something I don't know enough to create myself) (Martnym (talk) 20:12, 27 December 2008 (UTC))[reply]

Chalk River Unidentified Deposit[edit]

The page previously stated that the word CRUD originated from the acronym Chalk River Unidentified Deposit. In fact, this appears to be a backronym -- the dictionary etymology states that crud evolved from the middle english 'crudde'. RickScott 20:41, 13 July 2005 (UTC)[reply]

HTTP Mappings[edit]

The current article has create map into the HTTP method POST and update map into the HTTP method PUT. I believe that create should map into PUT and update into POST. The reason is section 9.1.2 of RFC 2616. This section states that PUT has idempotence. In other words, when performing the same PUT request N times, the end result (resource) will be the same. POST does not have idempotence. Therefore, if you are updating with PUT, you are changing the resource and breaking idempotence. --IndyGreg 04:59, 7 September 2007 (UTC).[reply]

I agree, either this mapping should be reversed or HTTP mapping removed at all. VadimIppolitov (talk) 11:51, 20 February 2012 (UTC)[reply]
The whole PUT vs POST dilemma is a nonsense because:
  • The standard hasn't been followed since decades, most webserver uses POST and GET and nothing more. So the use of PUT, DELETE and other are more "obsolete/archaic" features that very few system are using (excluding RESTful server).
  • The use of GET to obtain and POST for send couldn't be followed for every case. For example, a hyperlink to send a GET that store information (insert) or a POST to send a big object that return (read) some information about this object (for example to send a list and return the average).
  • So, the strategy to use GET or POST does not depend in the nature of the action (read, insert..) but in the nature of the website. And, for the same principle, PUT/DELETE could be (and usually is) replaced by standard GET and POST.
--190.162.98.84 (talk) 00:48, 11 February 2013 (UTC)--190.162.98.84 (talk) 00:48, 11 February 2013 (UTC)[reply]

My reading of Section 9.1.2 is that a PUT can result either in a create or a replacement of a record (eg a delete followed by an insert). Also, a POST may result in a combination of any of insert, update and delete. The fundamental difference in the semantics between the HTML verbs and the database verbs is that a database verb expects the application to know the state of the database before applying the verb, whereas the HTTP verb does not. For exampe, PUT means that the server should create an object if it does not already exist, and to replace it if it already exists. This does not map to CRUD at all. LucQ 08:00, 18 October 2007 (UTC)[reply]

I think this part should just be removed altogether; the behavior of HTTP methods is defined by the particular web application running on the server, not at all by the HTTP specification; so it makes for a very bad comparison to SQL which is strict and set in stone. -- intgr [talk] 01:19, 19 October 2007 (UTC)[reply]

One can use both PUT and POST to create OR update a ressource. Therefore a mapping to CRUD operations makes no sense for PUT and POST. The HTTP mapping should be removed at all. — Preceding unsigned comment added by 80.92.125.199 (talk) 15:04, 22 May 2012 (UTC)[reply]

I agree that the section should be removed. CRUD doesn't map as clearly/cleanly to HTTP "verbs" as it does to SQL. Furthermore, the heading of the section is "Database applications" -- HTTP is only tangentially related to this topic (if at all). — Preceding unsigned comment added by 24.215.76.114 (talk) 00:09, 29 May 2012 (UTC)[reply]

HTTP Mappings Resolution[edit]

I see that since this discussion was first started, not much has actually happened. Firstly, please let me clarify some details. Yes, you can create new resources on a server with BOTH PUT and POST, the difference though is that PUT can also specify the actual destination URI whilst with POST you leave it to the server to resolve. This effectively means that PUT is for replacing a resource with a completely new version, or as most people abuse it, to modify. I am glad to see that PATCH is acknowledged on this page, it is the method of choice when it comes to performing partial modifications on a resource. I think it's a fair point that most servers/clients fail to make use of the full range of HTTP methods properly, but that is mostly when it comes to actual websites, when we start talking about REST architectures it becomes a much more pertinent topic and as such I think this is a topic that should be covered hear, especially as this comparison is taught so frigging often, to pretend it doesn't exist is just insane. I will do my best to update the main article with this, along with try to explain about the limits of this comparison, please do respond if you feel strongly enough. Thecoshman (talk) — Preceding undated comment added 21:28, 20 May 2015 (UTC)[reply]

PUT vs POST is a subject of endless debate in REST world. Seems that there is no single correct answer to this as is also depends so much about underlying application. PUT for a modify and abuse..again there are different (non-ideal REST world) views on this :) Zdax (talk) 11:29, 9 December 2016 (UTC)[reply]

Origin[edit]

In the Dutch version of this page, the origin of CRUD is mentioned to be the book "Information Engineering" by James Martin, from the '70s. Which version should I believe? Tammojan (talk) 14:29, 30 September 2009 (UTC)[reply]

It's even better. It was published by Google in 1983 if current article text is to be believed. I think it's just an error in the citation - Google Books is a reference, not part of the body text. 「ѕʀʟ·✎」 06:47, 8 March 2013 (UTC)[reply]

DRULAB acronym as an alternative for CRUD[edit]

[Note: discussion copied from User talk:intgr#Create, read, update and delete -- intgr [talk] 21:59, 4 November 2015 (UTC)][reply]

Hi Intgr, the acronym DRULAB is relevant because it describes an important modification of the concept. Besides, it's for many parts of the IT industrie a law inside the European Union (with 500 million citizens it does probably matter a lot...). Since the European Court of Justice canceled Safe Harbor it is a major topic. I would refer to https://en.wikipedia.org/wiki/Safe_harbor_%28law%29, but the text is not up to date. You can look into the press release here: http://curia.europa.eu/jcms/upload/docs/application/pdf/2015-10/cp150117en.pdf and for the German Federal Data Protection Act, which describes the locking, please refer to http://www.gesetze-im-internet.de/englisch_bdsg/englisch_bdsg.html#p0305 — Preceding unsigned comment added by 89.244.202.126 (talk) 15:48, 4 November 2015 (UTC)[reply]

(For context, this is probably a response to my addition of {{Citation needed}} templates to the article)
I really don't understand what the EU safe harbour laws have anything to do with this topic. If I understand you correctly, you're saying that the term is used somewhere in EU laws? Even if true, I don't think merely being written in a law makes it significant enough, if the industry doesn't use it. I Googled for it and all I could find in the first few pages of results were mentions not using it to mean CRUD, and copies of this same Wikipedia article.
Please present argument for why "DRULAB" is important, rather than just stating it, and provide some reliable sources to back up that argument. -- intgr [talk] 22:16, 4 November 2015 (UTC)[reply]

MongoDB[edit]

Some back and forth on MongoDB here: https://en.wikipedia.org/w/index.php?title=Create%2C_read%2C_update_and_delete&type=revision&diff=699767159&oldid=699471255

I'd support having MongoDB here (Mongo is important, the fact that MongoDB uses CRUD is important) but we don't need to list it line-by-line like this and the supporting URLs should be refs (and less of them), not inlined. Viam Ferream (talk) 10:28, 14 January 2016 (UTC)[reply]

@Viam Ferream: You say "Mongo is important, the fact that MongoDB uses CRUD is important". Well, every full-featured data store supports CRUD operations — they're the four fundamental operations of data stores.
The rest of columns in that table are widely used standard protocols, not products. Why is MongoDB so important out of all the data stores that it needs to be named explicitly? -- intgr [talk] 12:36, 14 January 2016 (UTC)[reply]
CRUD isn't the only way to work though. Much of SQL isn't "CRUDdy" (and rightly so - it's a blunt way to do either partial updates, joins or large recordsets). MongoDB is distinct from SQL and is both big and novel enough that it's worth us explaining it so as to be an example of "How modern NoSQL practice fits into the old familiar CRUD model". If MongoDB is also based on CRUD, that's worth noting. Viam Ferream (talk) 13:14, 14 January 2016 (UTC)[reply]
Would anyone object to updating the table to include MongoDB? It would look something like this:
Operation SQL HTTP DDS MongoDB
Create INSERT PUT / POST write Insert
Read (Retrieve) SELECT GET read / take Find
Update (Modify) UPDATE POST / PUT / PATCH write Update
Delete (Destroy) DELETE DELETE dispose Remove
@intgr, MongoDB is both a product and a protocol. (Although the protocol is not more widely used than the product is.) ----2620:5:8000:2047:8C26:D89F:DC12:E5A1 (talk) 21:10, 12 February 2020 (UTC)[reply]
I see this dicussion is as old as 2016. Oh well, EAFP. ----2620:5:8000:2047:8C26:D89F:DC12:E5A1 (talk) 21:12, 12 February 2020 (UTC)[reply]

Verifiability[edit]

I'm tagging both § Often missing functions (added in April by an IP user) and § User interface (dates back to at least 2006, but edited almost exclusively by IP users, who seemingly never bother leaving an edit summary) as completely-unreferenced, and possible OR. Because... well.. they are. Wikipedia is not a textbook, and isn't meant to "teach" data science anyway. But even to the extent it is instructional, the content of this (and every) article should be a summary of cited, published works, nothing more. -- FeRDNYC (talk) 08:47, 5 November 2018 (UTC)[reply]

Second meaning as a sub-domain of IT[edit]

CRUD can also mean a type of application that involves data entry, and tracking of business domain objects such as money, customers, products, sales leads, the review process (work-flow), etc. Example: "I want to program video games, not CRUD."

Antihrust[edit]

My Art diskusions. Antihrust (talk) 14:14, 9 January 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Create,_read,_update_and_delete&oldid=1201226060"