How to prove it?
March 27, 2008 2 Comments
It seems commonsense to most database specialists that, for data-centric applications where the application does not need to be database independent*, for logic that is close to your data – data logic – and data-intensive operations, it’s likely to be more efficient for that to be in the database, to be quicker in the database, to be cheaper in the database (by dint of the database having already been purchased and therefore just being a proxy of time to develop), to be less complex in the database, to be faster to write in the database, to have less lines of code and to be just as reusable in the database**
But how to prove it?
Many of us have no doubt written plenty of demos and proofs of concepts that validate the approach of on particular approach/solution over another in specific circumstances.
But is there any mileage in a set of benchmarks, similar perhaps to the TPC benchmarks used to compare hardware and database vendors? Maybe this already exists? Maybe this is exactly what the TPC benchmarks could also be used for. But I’d be interested in a focus broader than just speed including complexity, lines of code, testability, etc.
Ignoring my particular database-centric interest, how useful would it be to have a set of benchmarks that could be used to compare languages or new features in a language?
It would certainly make for an interesting challenge for those looking to fight the corner for their particular favorite. It would be useful information for a new project trying to justify which technology / features / architecture to go with and would make a change from the just “let’s use feature X because it’s new and exciting”.
*I’m thinking here about vendor applications that need to be database independent to support N different databases rather than a misguided notions that it’s general best practice and it’s more likely that you might change from Oracle to SQL Server than rip out your C# and go all Groovy.
**When written by someone who knows what their doing, obviously.