SQL Server Yukon – Why put logic into the database?



That is a follow-up blog to my last one about SQL Server Yukon – as I got some interesting feedback on it!


 


Well, it depends…! Just think in terms of classical two-tier projects with not more than 100 users where leaving (very often changing) business logic in the database would have been useful and made deployment/update issues much easier – just reduce the costs!!!!


 


Okay, but let’s rethink the whole story from another standpoint – Service Oriented Architecture and the role of fiefdoms. A fiefdom is nothing else than a participant in an SOA scenario that exposes functionality through standardized interfaces (e.g. Web Services). Each fiefdom has a data store and exposes data and functionality through its interfaces. And SQL Server Yukon will be one possible platform for implementing such fiefdoms thus it will support many things that are necessary for easily building such fiefdoms. Why implement the functionality in SQL Server – again because to reduce complexity, safe costs – all with the concept of “keep it simple!”


 


I don’t say that we now should implement our whole fiefdom in SQL Server all the time – of course if it is necessary (necessary!!), we should still continue building n-tier distributed apps with presentation layer, business logic and data access in separate tiers. But now SQL Server offers the possibility of building back-end services and that’s the point.


 


So keep two things in mind: first of all in a SOA SQL Server is just another service while from the outside the service’s implementation is completely transparent (if accessed through Web Services no one will know, that SQL Server is running behind à loose coupling) and just be pragmatic and not always academic.


 


For more information on Service Oriented Architecture and Emissaries and Fiefdoms just take a look at the following links:


·       Pat Helland’s Blog
http://blogs.msdn.com/pathelland


·       MSDN Web Cast from Pat Helland – Metropolis
http://msdn.microsoft.com/architecture/enterprise/default.aspx


·       MSDN Mag Article
http://msdn.microsoft.com/msdnmag/issues/03/07/designpatterns/default.aspx


 


P.S.: To a comment on my previous SQL Server blog: don’t code your web site in SQL Server – web site coding is not business logic but it’s front end (presentation) logic and therefore not part of the core fiefdom itself and business logic.


Comments (9)

  1. Mario Goebbels says:

    Regarding your last paragraph, will it actually be possible to run a webserver within SQL Server? I always thought that the .NET stuff in there’s mostly for replacing extended procedures? I was pondering on trying that once the developer edition is available (whenever that is), but mostly only as fun project.

  2. mszCool says:

    Actually you will be able to create HTTP Web Service End Points that will be mapped to SQL Server Stored Procedures written in .NET or TSQL (on Windows Server 2003 without installing IIS because SQL Server is going to use HTTP.SYS).

  3. You have been Taken Out! Comments about your post on this link. Thanks!

  4. Mario Goebbels says:

    That means I could misuse SQL Server as simple web server that’s serving files out of a contained storage (a table with a varbinary(max) FileStream column) given there’s a SP handling the requests? Or does "Web Service End Point" mean that it’s mapping SOAP requests to stored procedures?

  5. mszCool says:

    NO, you definitely CANNOT misuse SQL Server as a simple web server. This functionality is for SOAP Web Services, ONLY!!