Uh, doesn't everything you do with a database reduce to CRUD?
I understand that sometimes you do the composition of many CRUD operations, but this is still CRUD.
I understand that sometimes you do the composition of many CRUD operations, but this is still CRUD.
But they also provide stronger typing and checking of the data. They provide a programming language neutral way to access the data quickly and efficiently. They index data to make queries on it faster. They do much of this automatically so you think it's all simple CRUD operations, but they also provide ways to explain what they're doing if it isn't working as expected. I can count the number of programs (not DBs) on my hand that I know of that can explain themselves accurately without needing a debugger.
Edit: I don't mean to be annoying. Most people on HN knew this and I'm not assuming you didn't, but while most people just use RDBMS for simple CRUD operations they're losing out on the power that these databases have been designed with.
However, I've come to dislike building business rules using the proprietary languages of the RDBMS vendors. In particular, I use Oracle and have been making a case with my employer to stop creating ties to Oracle by using PL/SQL as our house language. While it provides some efficiencies and can sometimes make coding easier, it can stifle development as easily.
I'm all for expressing data relationships in the RDBMS and using efficiency mechanisms like indexes and cost-based optimization. However, I now prefer business rules to be expressed outside the database.
[EDIT: Corrected anarbi to arnarbi.]
The question I pose to anyone consider this type of architecture is, how often do you switch database platforms?
I work for a moderate-sized university. The applications I support require up-to-date information in order to test modifications. They are read-intensive with few writes within the database. We can afford only one test database for the entire university. We refresh the database from production only once a quarter, at most. My applications would benefit greatly by being able to switch URL's to the production database in order to test a mod. Since our code, written in PL/SQL, gets stored in the database that it runs on, we can't do such a thing without significant effort: dblinks or modifying package names to store in production for testing or a test schema or whatever else you can think up.
Another issue is that PL/SQL is not a robust language for modern development. Its type-system was designed for strictness, which is great in life-critical systems. But, there is no notion of inheritance and no ability to write generic collections.
To mimic inheritance, you can create objects backed by tables and inherit one from the other. It has the feel of being bolted on and yet another tie to Oracle.
One final issue is that PL/SQL is highly subject to the resource management of the Oracle kernel. Often, the kernel is extremely efficient. But, there are times when you need code running in a separate address space, preferably on a separate server. For instance, one application I wrote is a batch system that has a lot of processing rules built into it. Our database is tuned for OLTP. My application is categorized by the DBA's as data warehouse-oriented. Yet my application has to run hourly throughout the day and compete with resources necessary for the OLTP stuff. Putting it onto a separate server, away from Oracle's kernel management, would more than likely help a performance issue we have.
So, the answer to your question is the one you were looking for. But, my concern isn't necessarily switching database vendors.
If table stakes for a database are more sophisticated than CRUD, what the hell is trivial enough to be CRUD then? Seems like a straw man.
Plenty of apps--perhaps more apps than not--use a database as a vaguely typed (MySQL out of strict mode barely gives a nod to them) multiplayer notepad.
Your DB either supports ACID or it doesn't. The term "stronger guarantees" is snake oil. It's either guaranteed or is not. That simple.
My first job was even writing dynamic web apps entirely in Informix.
Do you think of better ways to handle this nowadays? Is it more effective/maintainable to do this in the app layer?
But I don't know, I don't really do this stuff anymore. At Google we certainly have storage and database systems with a lot of non-CRUD features (look at Spanner for example).