I have received this question a few times from people e-mailing in – I have several posts that are C#/.Net focused, sans SSIS and CLR database references in implementation.
The easiest answer to this question is that I am a consultant in a company with a dynamic client base, so I need to be prepared to support multiple technologies related to my specialty and thus blog on those topics. Also, my background trek through the tech wilderness actually started with web development before moving onto warehousing, reporting and analytics.
Going deeper though, I think with the changes in the Microsoft microcosm that first presented themselves in the form of LINQ to SQL and now moving forward with Entity Framework are going to force a modifications in the way that database professionals, from DBAs to warehouse architects and SQL developers, learn, interact and what they are expected to know and have expert knowledge on.
Jonathan Kehayias posted a good discussion starter from a DBAs perspective back in February of this year, and it brings to point the necessity of learning and being aware of new methods, emerging technologies or new uses for existing technology. Data storage and the use of that data is at the core of almost any solution – whether you are wearing the hat of a DBA, business intelligence professional, warehouse architect, etc., we all play roles where SQL Server is at the core of our work, and it is our duty to advise as best we can how these new access and programming methods impact what I consider the heart of the solution.
Doubtless, this is a daunting task, as we not only have to keep up with the core changes to SQL Server, data storage technologies and other related bits, but now it is becoming increasingly important to peer over the void into that other world of UI, presentation and data layer technologies and be incredibly mindful of how developers will be (you wholly can't stop them, only curb) moving DML off to EF or Linq to SQL.
Putting the blinders and on and running down the hallway screaming "3NF and stored procs, or there is no conversation!" will do nothing but leave you behind – solution developers will just find a way around you in the end.
Keep in mind that I also write this from the perspective of a consultant at a "small" company – while my client work ranges from mom and pop to enterprise, my experiences are not going to be reflective of those who work in large shops and have the opportunity to specialize.
So what is the take-away? Why are there C# posts on my blog?
As much as we would like to silo technology and those that implement it, activities are solution driven and require a holistic approach. Information is at the center of all of these solutions and it is our responsibility to help drive any architecture and implementation towards the best fit for a given scenario. To that end, breaking out of your comfort zone in order to advise and influence the solution will always be better (and less stressful) than passively waiting for the battle to come to you.
I am not advocating becoming an expert in outside arenas, but simple activities such as attending a .Net user group meeting or participating in an application code review will go miles – cross pollination is good for more than just fruits and vegetables!
Couple of references, this conversation is not new!
http://weblogs.asp.net/dwahlin/archive/2007/11/15/the-linq-dilemma.aspx
http://articles.techrepublic.com.com/5100-10878_11-5897968.html
http://www.sqlmag.com/Article/ArticleID/96637/sql_server_96637.html
Tags: ramblings,
.net,
career,
architecture,
solution,
consulting,
sql server
Categories: General