blog.negative9.net/contents/articles/introduction-to-crud/index.md

---
title: Introduction to CRUD
author: geoff-doty
date: 2015-08-10
template: article.jade
---

Understanding CRUD operations, both apparent and implied

## Introduction

CRUD is an acronym for **Create**, **Read**, **Update**, and **Delete**. Each letter in the acronym translates to an operation to be performed, such as

- Create or add new entries
- Read, retrieve, search, or view existing entries
- Update or edit existing entries
- Delete/deactivate existing entries

The CRUD operations are at the heart of most dynamic websites, especially popularized by those created during the Web 2.0 era. CRUD is often referred to or most relevant when designing user interfaces for most applications. Those interfaces could be a GUI-based interface or as a low-level Application Program Interface (API)

Without these four CRUD operations, applications cannot be considered complete. Because these operations are so fundamental, they are often documented and described under one comprehensive heading, such as "CRUD operations", "content management" or "contact maintenance".

**CRUD Operations Translation to REST and SQL**

As CRUD is so paramount for most applications, most architecture designs and systems supports these operations, but often under different terms, such as:

|Operation| SQL | HTTP |
|---|---|---|
| Create | INSERT | POST / PUT |
| Read | SELECT | GET |
| Update | UPDATE| PUT /POST |
| Delete | DELETE | DELETE|

**Other Variations**

Over the years many variations of CRUD terminology were devised to help explicitly mention other operations that were implied by CRUD, for example the READ operation usually translates to ANY READ operation, including searching for a record to READ, READ a listing of records, and READ the details of a single record.

Because of these hidden, implied operations terms like

- SCRUD (Search)
- CRUDL (List)
- SCRUDL (Search and List)
- BREAD (Browse, Read, Edit, Add, Delete)

were born.

Once upon a time I used the term DICE, just so I could say "I'll DICE up that interface".  DICE stood for Detail, Index, Create, and Edit.  In this paradigm

- Detail reads the details of a record
- Index is the listing of the records
- Create or add a record
- Edit or update a record -- including marking a record as deleted

## CRUD Development Evolution

CRUD is an evolutionary process.  Below roughly explains how that evolution evolves.

>  NOTE:  This is usually called "EVIL-LUTION";)

### First Pass

Initially CRUD operations are dumb, that is to say they do what they are suppose to do with out any checks and balances.  For example a 

- **CREATE** operations create a records without any field validation and could include any or all of the fields defined in a record.
- **READ** operations read the entire data object, even attributes that would normally be hidden and designed to manage the object such as `is_deleted` or `created_by` that may have no bearing on what is trying to be read.
- **UPDATE** operations, much like CREATE operations have no field validation, no permissions to determine if a record can be updated or how it should be updated.  Typically update operations in the first pass perform a replace operation of the record potentially erasing a dozen fields to add one.
- **DELETE** operations delete all traces of the record.  This leaves holes in reports and breaks all but the simplest resources because of resource dependencies.  For example, if we were building a blogging application add deleted a *user* resource, the *post* resource would have an invalid pointer to a resource id that no longer exists.

### Second Pass

At this point we realize our need to add some intelligence to our CRUD implementation so we do not get support calls at 3AM, because someone deleted a user accidentally and now any resource tied to that user is throwing errors.

- **CREATE** operations are now restricted to a data dictionary, defining required fields, data types, data lengths, and other validation rules so we do not accept junk data.
- **READ** operations now adjust the fields returned to the context of how we want to read that data; Reading a list of records only return a small subset of features to reduce bandwidth and increase the speed to deliver and render the content.  We start adding additional functionality such as paging, sorting, and searching for records.
- **UPDATE** operations now obey the validation improvements done for create, and tend to do a true update and not replace operation.  This allows a user to change his/her name only 
- **DELETE** operations are no longer permanent irreversible operations, but rather a simple hidden flag added to the record to identify that it has been deleted.  Like a truly deleted record, it doesn't show up in read requests or search results unless specifically looking for deleted records.

### Final Pass (Enterprise Class)

In our final pass, security plays a huge role as to whether an operation can be performed, such as those associated with user permissions.  Additionally detailed logging is added to all operations in Activity Logs or Audit Logs.

## References

- https://en.wikipedia.org/wiki/Create,_read,_update_and_delete