The Oracle Speaks: Pricing Must Be More Complicated

I guess that's the idea, isn't it? Keep the model complicated enough that the technical details just "wash over" middle-level management. All they will hear will be "The team thinks we should go with Oracle. It's what we've got on the other projects, so it makes the most sense."
My disclaimer: I really like the Oracle database. I think it is one of the most sophisticated, scalable database architectures on the planet. If I had a zillion bucks, the only thing I would ever use would be Oracle. (Or course, SQL Server and DB2 are constantly being upgraded. I'll reserve judgment on those emerging versions until I see where they go)
But this has got to stop. Oracle is making things much more complicated than they have to be. And I believe it is on purpose. The sad but simple fact of the matter is, for most small and mid-range database solutions, the platforms are not worth the cost of admission. That's not saying there isn't some sort of enterprise argument for using one of the big guys everywhere -- I'm sure there is. But at the local level, it's all "inside baseball", which is a nice way of saying it's a lot of technical details that don't mean squat to the success of the project.
Moore's Law is working wonders on this segment. Got a thousand users in a shop doing some IT work? I've got news for you -- you can be perfectly happy using BillyBob's Database-O-Rama package. And probably save a lot of money doing it, too. Sure, one of the big boys would be sexier; but you don't need it. Not really.
So I hate to break it to you guys, especially the DBA types, but project-level database work will become generic. There's so much code that's open source, so many combinations of functionality, and guess what? It magically gets faster just by sitting on the shelf.
So we're in the odd position of buying these products not for project and program support, but for enterprise support, even though most enterprises will never use all the bells and whistles they are buying. This is yet another example of the "tool fixing the process". We all want more coordinated database development and usage, so we buy the tool to make it happen. Never mind that it is the people and the processes that are going to make or break you here, which has nothing to do with the gizmos and gadgets.