All this is anecdotal of course - but this is a good talk that gives a pretty nice perspective on the whole thing: http://www.youtube.com/watch?v=-zRN7XLCRhc&feature=player_de...
All this is anecdotal of course - but this is a good talk that gives a pretty nice perspective on the whole thing: http://www.youtube.com/watch?v=-zRN7XLCRhc&feature=player_de...
From the other side, I work at a medium-sized consultancy that handles Oracle databases as well as other products. I work with open source, big data technologies (Hadoop, Mongo, Cassandra), and I talk to some of our top Oracle guys sometimes. Oracle does everything, and it does it damn-near automatically - look at the concepts guide (http://docs.oracle.com/cd/E11882_01/server.112/e40540.pdf) if you want to see how many types of JOIN an Oracle DB can choose from. Exadata has more, I think, and half the performance stuff isn't even documented, it's just buried in query plans. I'll tell an Oracle guy, "hey, we just got hash-bucket joins", or skip scans, or some other enhancement, and it's like the OSS competition is still in the 90s compared to what Oracle can do.
You can complain that Oracle charges a lot of money, but in a lot of cases it's NIH syndrone. Drop in Postgres instead, then spend 6 months tuning it, or spend the difference buying extra hardware to scale out. Roll your own ERP, and forever have a small dev team of 4 guys who cost you half a million dollars to support it, because you didn't want to buy off-the-shelf, because your pride as a developer stops you from learning someone else's tool.
In Oracle, not only is the DB going to actually look at the query's real performance by itself, but i can just tell it to change the way it runs at runtime, if all else fails.
There's also data warehousing tricks that, AFAIK, Postgres does not support. In Oracle, if I have a star pattern, I can make the queries run without actually touching the fact table, only querying indices.
That said, exadata is voodoo, compared to how much more predictable Postgres' behavior is. But there really is a case for it if you really are building the DB equivalent of the Titanic.
Most complaints I've seen relate to stuff like this. Bad customer service and destructive behavior.
> and forever have a small dev team of 4 guys who cost you half a million dollars to support it
You lose me there. Don't tell me I won't need people to run my Oracle databases. Moreover, I'll need "Oracle" people, who earn 2x what those other 4 guys earn.
This is sadly true for most proprietary IT. What would be the solution? A rigid code of ethics that would prevent IT executives from meeting their vendors outside the office?
I once worked for a company that had its CTO fired because he accepted a trip to Paris (so he could speak at a vendor-sponsored event), but only after buying a couple million dollars of inadequate and overly expensive hardware. Now he's a senior exec at said vendor.
Hint to senior IT execs: if one of your providers names you "Executive of the Year", watch out: it's probably because you are their most profitable cash cow.
Not a solution, but I think this is in the right direction:
A business model in which IT execs with purchasing power have a vested interest in seeing the business succeed -- either financially or from an purely-engineering perspective. I believe the first point speaks to itself. The second, while it aligns with my bias that engineers make better tech execs (the engineer that 'works his way up' comes with perspective, knowledge, and wisdom), I still believe that engineers look after each other and at least know when they're fucking over the next guy for some wine or a couple days in a different city.
Unfortunately, this is my only suggestion because it's hard to do an ethics-test that's relevant and it's reasonably difficult to fire execs that you know aren't honor-bound.
>A rigid code of ethics that would prevent IT executives from meeting their vendors outside the office?
I've been taken out for drinks by vendors trying to close a deal. None have yet. When I grow a personal business to the point of free trips, there's a chance I'll take those if they don't interfere with my performance or come with a moral price-tag.
Which is to say, there's nothing inherently wrong with meeting salespeople outside of the office -- it's a just a conversation and "practice business." If the vendor is selling something interesting, who knows, maybe it's worth comparing against your current solution.
This is somewhat of a cherry-picked hypothetical anecdote, but I wouldn't choose any solution that makes for pissed-off engineers or burns money.
>I once worked for a company that had its CTO fired because he accepted a trip to Paris (so he could speak at a vendor-sponsored event), but only after buying a couple million dollars of inadequate and overly expensive hardware.
That's just corruption and lack of oversight. I realize that at some point, you have to trust the decisions of your CTO, but if he doesn't have significant skin in the game (and a couple million dollars isn't chump change to the company), this purchase order should have triggered a review of the proposal.
However in this specific case, if Mozilla issued a takedown to w3schools, would we be up in arms about it? Vendors are generally pretty tight with documentation when it's a cut-throat sector.
Yes, yes we would.