Final CLR Response
Today one of our readers digs into a topic I connect with every once in a while regarding the role of your database server. The key question is, “what kinds of roles do you want your database server performing?” As I work with larger and larger databases, my tendency is to put the least amount of extraneous work on the database server as possible.
That being said, I have had to do things I would not prefer simply because some companies have no other place to do it. For example, on one system I used SQL CLR function to compress and decompress blob data simply because there was no other place available to do the work, and the database was the only centralized place where compression could be implemented. Ok, it was a bad solution for a bad architecture…but it was the correct decision for that specific situation.
Let’s pretend it is a perfect world, and you are designing your systems to scale out, not scale up. That being said, what limits would you prefer to place on your database server, and even more specifically, your database engine?
Dirk Writes:
Personally, I feel that Microsoft should strongly consider adding this feature to SQL Azure.
Even if their system is not an open source system, this backdoor has offered us, IT-professionals, a chance to enhance the DB-servers capabilities considerably. In my company, most of our add-ons (like functionality for Regular expressions, string-manipulation, XML/XSL transformations, HTML-decoding, …) in one central DB to be used by all the other applications as they see fit and it has saved us quite some workarounds and ensured that my team of data architects can easily intervene when clean ups of data are needed, directly from SSMS or SSIS packages.
Now, concerning those who have warned us not to use it, the eternal question remains:
Should you use your DB-management system as a dumpster with some indexes and keep out all intelligence in the application-code?
Or should you make use of the features it offers and for which you (or your customers) have paid anyway?
For a software vendor, it makes sense to keep the data and the logic separate to ensure portability, but I feel that a lot of companies are not prone to easily throw away their infra-structure and to "just" change to another system.
Sure, this is a somewhat controversial topic…at least people get heated up about it, or have very strong opinions. So, why not share your opinion, strong or not, by sending you thoughts to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Installing SQL Server Express 2012 and managing the LocalDB
This article discusses downloading and installing the 64 bit version of the SQL Server Express 2012 on a (x64 bit), Windows 7 Home Premium on a Toshiba Satellite P775 and administering LocalDB using Sqllocaldb utility.
Featured White Paper(s)
SharePoint 2010 Enables the Enterprise
Written by KnowledgeLake
read more)