Written by A couple days ago I was working on some homework for one of my programming classes. We’re learning to program Android OS phones using Java and this particular exercise had us learning how to interact with a SQLite database. Looking through the tutorial of this there was mentioning of “giving basic CRUD functionality” to the system through this Database Adapter that had been written for us.
When I first read that line I thought, “CRUD? What the heck is that?”
Well, dear friends, the answer is that CRUD is a check list of features a database must implement to be fully considered to be a database software, or any other form of “persistent data storage“. It stands for “Create, Read, Update, Delete”, and it stands as a list of abilities that a database requires to be fully functional.
Now if you look down the list of alternate abbreviations for crud, if you’re a star wars geek, you’ll see a VADE(R) listing. This, in and of itself, stands for “View, Add, Delete, Edit, (Restore)”. This particular flavour, with the addition of the Restore on the end, is something used for transactional databases, or databases that keep a log of actions for a specified amount of time, or a specific command is given, and allows you to undo any changes you make before making them permanent on the database.
My theory is, what if we didn’t apply this to just databases and persistent storage. What if we used this as a programming paradigm to interact with data in the first place?
If you really break it down, almost everything on the web has to deal with persistent storage (through databases or flat files or whatever) in one way or another. Most ideal target? Service sites like youtube, or photobucket, or even deviantArt. Or heck, ANY forum that you’ve been on in the past 14 years, including email and google searches. All of these different technologies deal with persistent storage in one way or another.
Now, the likely hood of this already being in place, whether the designer knew about it or not is a completely different story. The point I’m trying to make is that when it comes to using data (viewing, manipulating, etc) there’s a certain way that we should deal with it, and for me personally CRUD is just too broad and too overbearing.
I prefer VADERPS. Why? Because it keeps the separate functions, well, separate, and small. And I like small, because small is fast, small is easy, and small is awesome. Though, what does VADERPS stand for? Easy. I’m sure you’ve noticed by now that it’s based off of VADER, so that part is easy. View, Add, Delete, Edit, Restore. The P stands for Purge, and is based off of Delete in that Delete deals with one, while Purge is optimized for multiple deletes at a time. That S is also more or less based off of View. The S stands for Search and like Purge instead of dealing with one, it deals with many. In all, you have View, Add, Delete, Edit, Restore, Purge, and Search.
That specific separation between View and Search, and thusly Delete and Purge, is a distinction I feel like I have to make. As View deals with just one object, Search deals with many, and CRUD combined the two into “Read” and I’m sure a bunch of others in that list do the same thing, or word the acronym in such a way as to support one or the other such as ABCD and it’s Browse idea. The closest one on that list that comes close to my idea is VEDAS (view, edit, delete, add, search) but the restore functionality (and mass deletion) is a nice trick too, you know, though the distinction between mass delete and single delete has a different reason behind it.
I chose to separate out Delete and Purge because if you think about it, if you do a mass deletion (such as say all of March of 2007 on your blog or whatever) then having a function that deletes all of those one at a time is a bad idea. To put this into perspective it’s like looping through the lines of a file on linux manually to find the right line you’re looking for, when you could have easily done it using a grep command. Grep loops through the file for you, and does it at a much more efficient rate than any form of looping and file handling you could have come up with did. In this case, looping through the file on your own is like using delete one at a time per blog id that you want to delete, whereas using grep is like the purge, where it does it for you at a much faster rate because it takes out the middle man. In straight up SQL it’s the difference between calling this a bunch of times:
DELETE FROM TABLE WHERE id=x;
and doing this:
DELETE FROM TABLE WHERE id IN (x, y, z);
The overhead of having PHP loop through making that first call for you for x, y, and z is a HECK of a lot when compared to just having MySQL do it for you efficiently.
I bring this up for a reason. I’ve been through many a site that doesn’t allow a user to edit comments that they’ve already made; or I’ve been through some form of code on a website that doesn’t allow a programmer to easily say “This is the summary, here’s the detail.” And on no site what so ever have I ever seen functionality of “Ok, we’ll take this out, but won’t make it permanent for the next 12 or 24 hours just in case it was a bad idea and a case of the ID10T virus”, when just keeping the data in a temporary state of “garbage collection” status would have been the simplest way to fix the problem*.
So here’s what I propose, in quick format:
VADERPS:
View – One item at a time, usually linked to by a Search, contains all details necessary about that item.
Add – Name says it all. Adds an item to the system, depending on the item type and data required.
Delete – Deletes one thing, and one thing only. Optimized for deleting said one thing.
Edit – Edits an item. It’s only logical to have to edit one thing at a time and so no “Multi-edit” functionality needed… Yet.
Restore – Means keeping an item in a state of purgatory, just in case the user hit the wrong button.
Search – Optimized for viewing multiple items at once, contains a summary of details about all items.
In all, the fact that there’s a clearer distinction between different /types/ of data sets (individual vs. multiple) will make things simpler in the long run design-wise and faster optimization-wise as keeping things simple and stupid is the way to go.
*Note: I actually talked to the CEO of a company who had to revoke the admin priviledges of a client he had using his program, because even after /three/ “Are you sure you want to delete this?” messages, still deleted things off of the system that really shouldn’t have been deleted in the first place. In this case it’s better to have things be transactional, and keep them in a temporary purgatory status for 24/48/72 hours or whatever so that they appear deleted but are easy to recover just in case.
