CRUD is an acronym for the four basic types of SQL commands: Create, Read, Update, Delete.
Sticking to those four basic operations when dealing with models (of your data structures) and relationships between them can make handling the project easier as abstract things like join tables now have a real name and can hold real data (instead of two foreign keys).
It makes more sense in a Web application environment to match HTTP verbs with CRUD operations:
- GET - Read
- POST - Create
- POST - Update
- DELETE - Destroy/Delete
Each model in the project, for example in a store application one might have a collection of Products for sale, Categories of Products, and Customers that buy browse Categories and (buy) Products. In a RESTful application (one which does the above verb mapping) each instance of each model gets it’s own URL, such as:
- /products - refers to all of the Products (POST a new Product to this URL to add it to the collection)
- /products/1 - refers to the Product whose ID is 1 (RUD operations are done on this URL)
- /categories/1/products - In a properly set up application this refers to the Products that belong to the Category whose id is 1
- /customers/1/products - This could refer to the products the Customer whose id is 1 has purchased.
This contrived example is incomplete (there is no shopping cart!) and there models are simple. However our store just had a holiday and we gave special codes to the top 100 customers to redeem for a free hat. There’s now a model called Coupons (and they would live at /coupons with a cool GUI for the store manager to tinker with) but there’s nowhere to redeem the Coupon. It doesn’t make sense to do it with the Customer model or the Product model because there’s nothing in those models that stores that the Customer has redeemed a Coupon. Looks like we need a join table with columns coupon_id and customer_id. But we don’t know when they redeemed it and there’s no way for them to store cool feedback saying congrats on the holiday.
At this point I would like to remind that this is very contrived.
There’s got to be a better way to do the redemption of Coupons and get a free Product. And there is, I think (otherwise I wouldn’t have this blog), CRUD to the rescue.
Call the new thing a UsedCoupon. It still has the attributes from the old join table and perhaps a timestamp and text field. Creating a UsedCoupon is equivelant to the act of redeeming (and getting the cool Product). Redeeming it is POSTing a new UsedCoupon object to /used_coupons; the associated product is given to the Customer and I have a reason to blog.
I happen to like the limitations because it’s illogical to add unnecessary methods onto controllers (in MVC terms) when there’s no need. Why not just make another URL, they’re cheap. CRUDdy controllers will be lightweight since there aren’t many methods (a typical max of 5!). Rails happens to afford the developer helpful methods to generate the right URLs from models.
To answer the question What is CRUD? I answer: CRUD is helpful.
