A question came across StackOverflow yesterday asking whether it was better to perform sorting or filtering within a stored procedure or in the business logic layer of an application.  This highly depends on the application and your needs.  The general approach I use, and is based on advice given by those with a few more gray hairs than I have, indicates that filtering and sorting should be placed within the stored procedure logic. 

The reason for placing this functionality within the stored procedure is due to the fact that SQL Server's database engine can better handle the load of performing these tasks than a web server (which is possibly hosting multiple sites with numerous users).  Obviously, this practice doesn't fit for all cases such as those in which you need to allow the end user to do their own sorts or perform their own filtering.  Providing end users with this functionality...

Thoughts on Proprietary Database Structures / Data Dictionaries:

Database developers, especially those offering hosted solutions, must keep a tight rein on their database table structure, field definitions, table relationships etc.  This is just part of providing a secure and stable product.  I've seen instances where the data dictioinary for some schemas are considered intellectual property, protected by copyright and could only be shared upon request to registered customers.  I have some issues with this scenario and the companies who utilize this model tend to force their customer base to incur additional expense to hire vendor consultants to develop custom reports not otherwise included in the licensed product.  Is this "open source"?  (sorry, rhetorical question)  Perhaps, this business model could benefit from allowing skilled developers to create database views or OLAP cubes...

I received some excellent advice from the gang at the Sharepoint LinkedIN group this week regarding the setup of a virtual development environment.  One of my areas of focus has been Sharepoint development.  You might recall that Sharepoint 2010 was released earlier this year, which is great news!  However, for those of us running 32bit test servers, it wasn't such great news because the new version of Sharepoint will only run on x64 machines.

I had a few options that involved some monetary or time investment:

Install Sharepoint 2010 on my Windows 7 desktop.  It's a x64 system and complies with the minimum requirements of Sharepoint.  The downside is that it clutters up the system with extra overhead and the application is not leveraging the full capabilities of a server. Upgrade my x86 test server.  This old Dell has been a trooper.  It runs Windows Server 2003 and has been used as a test environment for my client projects.  I used it to do some web part work in MOSS 2007.  Clients can...