The way I look at it is that a database, much like Linux, is a platform. I very seldom look at the source code for either for day to day programming.
As popular platforms they have in common that they are very well tested through everyday use, and are likely to operate as documented for ordinary configurations.
When you can rely on the correct operation of the system, the code of the underlying implementation is irrelevant. What you care about is how well the system supports your requirements, and what performance you can get by tweaking the available knobs.
Contrast this with your average 1000 line script. It has simplicity on its side, but when something breaks, that script is a suspect, and the source code of your DB probably isn't.
> Consider Prevayler, for example [...]
I'm not really sure what you're saying here. That an in-process in-memory object persistence framework without indexing can be faster than a heavy-duty relational database? That's not just "less code", that's "less features". Or "different features", at any rate; they're not the same species. I'm just going to assume what you mean to say is, "Not everyone needs a relational database".
> Also, your 15 MLOC for Linux is a bit of a red herring. [...]
All the more reason that the LOC count by itself is a meaningless metric.
Sure, databases are a platform all their own. Like any platform, as long as you are operating well within the expected envelope, they work as advertised. When you get near the edge, though, you really need to understand how they work. As we are seeing with the rise of all sorts of RDBMS alternatives, a lot of people are getting near a lot of different edges.
The ability to understand how something works is a function of complexity. LOC is correlated with complexity, so it's a good rough metric. If you have a better one, please offer it. But otherwise I'll stand by my original point, which is that the guy bitching about 1000 lines of consistency code is ignoring the much larger amount of code used in alternative approaches.
What I'm saying with Prevayler's example is that if you don't need all the features of a database, then the extra complexity is a drag on what you're trying to get done. Less features means less code means less work to master.
> All the more reason that the LOC count by itself is a meaningless metric.
Yes, you throwing in a bullshit number is definitely proof that all numbers are bullshit. Bravo.
The way I look at it is that a database, much like Linux, is a platform. I very seldom look at the source code for either for day to day programming.
As popular platforms they have in common that they are very well tested through everyday use, and are likely to operate as documented for ordinary configurations.
When you can rely on the correct operation of the system, the code of the underlying implementation is irrelevant. What you care about is how well the system supports your requirements, and what performance you can get by tweaking the available knobs.
Contrast this with your average 1000 line script. It has simplicity on its side, but when something breaks, that script is a suspect, and the source code of your DB probably isn't.
> Consider Prevayler, for example [...]
I'm not really sure what you're saying here. That an in-process in-memory object persistence framework without indexing can be faster than a heavy-duty relational database? That's not just "less code", that's "less features". Or "different features", at any rate; they're not the same species. I'm just going to assume what you mean to say is, "Not everyone needs a relational database".
> Also, your 15 MLOC for Linux is a bit of a red herring. [...]
All the more reason that the LOC count by itself is a meaningless metric.