Why a SQL or BI developer should learn .Net

PingBack from http://topsy.com/sqlblog.com/blogs/jamie_thomson/archive/2010/07/05/why-a-sql-or-bi-developer-should-learn-net.aspx?utm_source=pingback&utm_campaign=L2

I think your reasoning is sound.

In an ideal world, the database design shouldn't affect the application design and vice versa. However, in the real world, we often have to make decisions and tradeoffs in order to have an app that can scale. Therefore, I personally think both application coders and database devs/DBAs should understand the other technology enough to know when it is appropriate to do something less than optimal on one side because the benefits on the other side will make up for it.

I personally am a C# guy, but knowing TSQL and SQL Server to some degree of depth has really helped me as a developer. Having this knowledge has also helped me to relate to, and communicate with, the DBAs I work with. I think the reverse would be true for any DBA.

In addition to learning .NET, I would encourage DBAs to keep an eye on trending architectural strategies such as Not Only SQL (NOSql), command query separation (CQRS), event sourcing, etc... As time goes on, I'm sure many developers are going to advocate doing away with the traditional "one true enterprise database" etc... If the DBAs are not up to speed on these architectures, the wrong choice could be made.

Absolutely agree on avoiding compartmentalization which comes from expecting team members to wear blinders.

DBAs, database developers, client developers - all need to have some understanding of the viewpoints of the other parts of the architecture.

A DBA who doesn't understand developers will cause developers to work around the DBA instead of with the DBA. etc. etc.

At which point the system will lose cohesion.  I would say it is the responsibility of the architect to create a structure and a vision/road map which ensure that developers in the different roles work so that their component of the system is in harmony with the overall architecture and not overreaching the design.

Ultimately an architect is balancing the needs of maintenance, cohesion, coupling, etc.

So, for example, if a developer says that the database needs to be a dumb repository and the architect was relying on the database layer as a consistent data services, then the final result is not going to meet the expectations of the architect.

I completely agree - it's nice to hear someone from a data-centric background say it.

The appreciation of integration is especially useful when working with products like SharePoint - which require .NET skills to customise, but are mainly sold to decision makers because of their BI capability.

I'm actually a .NET developer who fell into BI by accident - before that I was an Access developer, which was a useful apprenticeship in appreciating that the life cycle also includes BI assets (e.g. reports).  The fact is that they are not completely separate worlds and an understanding of both leads to much more robust architectures and agile applications.

Agree with you on the need for some cross training.

Coming from a development background to the land of data has proven useful many times.  Having general knowledge of .NET architecture, patterns and the data access technologies has proven useful as LINQ/ORM type stuff becomes more prevalent and a part of mainstream data access.  The ability to work with the development teams and talk their language (to some degree) has proven useful when I want to work on tuning/profiling the generated code.  It would seem that they are more willing to come to the table to talk performance, etc than if we were separatists and just played departmental politics.  (DBA says no, they say procs cause their deployments to be late, etc)

Talking their language, and learning ancillary technologies just buys more "cred" with the "arty" .net types :)

Great points, Jamie. Thanks for sharing!

Lee

PingBack from http://www.pythian.com/news/14333/log-buffer-194-a-carnival-of-the-vanities-for-dbas/

PingBack from http://www.weez.com/2010/07/pythian-group-log-buffer-194-a-carnival-of-the-vanities-for-dbas/

Another good point for a BI guy to learn .NET is so that you can develop your own scripts in the Script Component/Task in SSIS.

I've learned myself VB.NET right before I started working in BI, and now I'm "the .NET guy" of our team when it comes to scripting in SISS :)

Cross discipline knowledge is also extremely useful for determining where a piece of functionality is best implemented - rather than seeing only nails just because I'm a hammer, one can identify when it's time to use a different tool, even if that might require a different carpenter.

And yes, my home is currently being renovated :-)

Agreed, I consider myself a C# developer, but do a fair amount of database development too, such as SSIS.

Specialization can make you a one trick pony.

Of course there is something to be said for being good at what you do and if you don't have the extra time then at least be good at your primary role.

Yes,truely agree,It encourages me more to learn .Net.

We can develop SSIS custom components for different uses and whole object model (like dynamic SSAS object creation and processing) is there to see and program for smart/automation application.