CRUD in, CRUD out

I was a little taken aback when someone told me I was responsible for the "crud" operations on a database project. Huh? Ah, I see - it's an acronym for "create-retrieve-update-delete" - C-R-U-D.  OK, so let's see what this means.  It means that for every table in your database, you have a set of single-row operations to perform create/insert, retrieve/select, update, and delete.  OK now we have our database and we have our primitive operations on the data, now we're all done! But if this is what you ask of your persistence framework or other database interface, you are not only asking the wrong question, you're asking in the wrong language.  Every supposed limitation of relational technology can be seen in the "CRUD" mindset.  That is, if you want CRUD, you will get crud. You see, relations or tables are really not what anyone wants to manipulate immediately — not even I, and I am pretty diehard relational.  We all need to combine data in order to make something of it.   CRUD completely falls down when you start to actually use relational data in a relational fashion - with joins, references, lookups, and all.  The point of relational is not that the simple relation or table is the end-all ultimate representative or usage of the data.  It's that it is a building block for limitless uses of the data. When you limit your application to a CRUD database interface, you are fundamentally crippling your ability to use the power of the relational model.  For this reason I have sympathetic skepticism for Hibernate, JPA, and other "POJO" (plain old Java object) ways of interacting with the database. Any substantial database application should instead use the Model-View-Controller pattern pioneered by the Smalltalk people back in the 1970s.  I cannot believe it is a coincidence that at the same time relational database technology was productizing its notion of "view" which is essentially the same as the MVC "view": a decoupling from and recombination of lower-level data entities. Hibernate devotees will point out that Hibernate has been growing more capabilities that allow it to use more open-ended queries or views, that provide caching a bit more like business objects and less like flat data records.  All of these, however, are only working around the architectural limitation. (How many times have I seen this?  Too many!) With the architectural limitation, unfortunately, comes the worst limitation of all, which is preventing designers, implementers, and product managers from seeing the intrinsic possibilities of the data they are storing.  You will never, ever be able to make strategic use of your valuable data assets if you treat them like CRUD.