Recovering Oracle Developer
When I ran across this via Alex’s twitter feed a topic immediately popped into my head: The age old debate Oracle vs SQL Server.
I call myself “a recovering Oracle developer” now as my whole career, prior to my current role (data architect), was spent working with Oracle and PL/SQL. In fact, during the interviews for this role five years ago, the plan was a greenfield build out of a next generation data platform using Oracle as the backbone. Long story short, Oracle sales guys lost the deal. By default, the choice was SQL Server 2012. I found out about this decision when I started the job.
I have to admit that gave me pause and caused me to seriously consider my options. I had always believed that SQL Server was very inferior to Oracle in just about every way. Could I transition to using a database system geared towards small, simple use cases to back the enterprise data platform I was to design? Did I want to give up working with the premiere enterprise database to work with what I perceived as an interior product?
Prior to this role, I had never used SQL Server and my colleagues shared the view that SQL was not an enterprise-level product like Oracle. The Oracle DBAs and I believed SQL wasn’t designed right from the start. “What do you mean you have 100+ SQL databases? We have 4 Oracle databases running our entire enterprise.” It was these broad generalizations and overall inaccurate misunderstanding of SQL which was clouding my thinking.
Initially, I took some time to learn to translate how SQL works vs Oracle. Explicit database transactions in SQL vs implicit within Oracle, SQL database instance equates to an Oracle database, the SQL EXCEPT keyword matches (a more appropriately named) Oracle MINUS to name a few. These conversions continued as I still thought like an Oracle developer trying to do something in SQL.
As I continued to work with SQL, I came to appreciate a number of things quickly. SSMS for one was vastly superior to the Oracle command line or the crap GUI Oracle tried to push out a number of times. That product in itself was a big productivity boost for me. As time passed, I came to appreciate SQL more and every feature I was looking for could be found though sometimes with a different name. The surprise to me truly was how close the feature sets were between SQL and Oracle.
I know a great deal of my perceptions, in the past, were based on dated generalizations with older versions of SQL where the gap was more significant. My preferences were more cemented by local familiarity for using Oracle over SQL rather than based on objective fact.
At this point, I’m very comfortable with SQL capabilities and tend to think “SQL first” and have some issues translating back to Oracle when needed. As we’re moving towards migrating our data platform to Azure I feel that SQL is the correct decision for our organization moving forward.
So what have I learned after all this? Both databases are good options which can support most data requirements that I run across and that the preference is more based upon what we are familiar with and less on pure product decision. Another area of surprise for me was the robust community of SQL developers freely sharing knowledge. SQL Saturday’s for one is a great example of the community commitment to raise the collective knowledge of the developer base by presenting frequently. I still consider myself “new” to SQL community and continue to learn every day and I’m glad I decided to take a chance to work with SQL instead of staying as an Oracle developer.