The right database
When it comes to databases, I have always liked the usability of SQL Server. I like being able to build diagrams that automatically rearrange themselves. I like the tools for setting up replication, but I would probably never recommend SQL Server to a client given the free and open database products that are available. The alternatives are amazing, and most of my clients have simple needs that can be met with some of the good open source database products that are available. My clients have tight budgets. Everybody has a tight budget!
Any time I have used Oracle, I have found that my clients did not fully exploit the product. The superiority of Oracle should never be a good reason to continue using Oracle as far as I am concerned. Even though all of my Oracle clients had full time Oracle DBAs, the DBAs operated in a separate silo and were not directly involved in helping me write my application.
In one case, the DBA was of no help to me, except that he was obviously disgusted by the fact that I was using Microsoft products. I never met with him because he was in another city, and he prefered email and the phone, in that order. Another DBA was not even interested in my participation or my ideas – he wanted my requirements, and he wanted to build the tables and provide views himself. He knew nothing about the application I was building! Twice, I had to tell my client that the DBA was an impediment to my progress, not a help. In the end, these unhelpful DBAs were told to hold their noses while I completed my contract and to stay out of my way.
I like to see Oracle on a resume, but that is about it. An Oracle DBA is more likely to know certain things, and SQL Server DBAs tend to think a database is something you just slap under your application to manage the data. SQL Server is easy to use, but that attracts some real amateurs.
On the other hand, I have never worked on a project that would have been better if only we had used Oracle, but I know that such projects exist. For example, I would use Oracle if I were working on a database that managed information about individual stock market transactions. This would be a high volume requirement. However, Oracle wants us to believe that their product is required in ALL cases, and it is not.
I have seen bad databases with tables that were not even in second normal form that were built using the best database products around, including Oracle, Sybase, and SQL Server. Therefore, I would say that proprietary database products are not always required; also, using a proprietary database is no gaurentee of success at all. The number of people building bad databases with Oracle is probably legion. (When I say that they are bad, I am also aware that many successful businesses are run using these pieces of crap. I am a snob, and I know it.)
The right database is not just a matter of choosing the right database product, even though the vendors want you to think that. The right database is a database that is properly designed. This industry emphaisizes the tools more than the products we produce. At the end of the day, using a good tool does not ensure that the work is good; nor does using a less robust tool mean that the product is inferior. Many database built using Oracle use features that are readily available in MySQL or Postgres. It would be better to have a good designer building your database than it would to build the database using a bad designer. A good designer knows your busines, and has been doing his or her work for a long time.
Giving a smart kid the latest tools makes for colossal mistakes not for success. In the enterprise, I support the idea of cross-generational teams. The young people keep the old farts up to date on new ways of working, but the old farts have a lot to teach the youngters, too.