collection, which can provide more than one way to find an item, i.e. multiple keys, a truck by tag,Feb 19, 2007 at 1:32 PM
odujosh wrote:I think your all being silly. SQL Express is free. Why reinvent the wheel? SQL Server team is a group of developers whose whole job is to make a database product the best they can. Why would anyone as a single developer waste their time doing something that in the end would be suboptimal.
Key issue besides the 1000 foot view making hash table idea look silly:
If you do any type of sorting or more likely changing sort per user input during process guess whats going to happen anyway. Yep that's right a linear path. Hard to sort without touching each item at some point.
Not saying little guru's approach is not admirable. Its just silly to think you can do it faster than SQL given average programmers priorities and some type of deadline looming.
What's silly is to dismiss an approach without thinking about where and when it might be applicable. Also, if you read the original post, it seems to be more about searching than sorting.
I used this approach in an N-Tier database linked application. Why? Speed. Loading everything into memory and allowing multiple searches on the client tier was much faster that returning to the database every time. Yes, an SQL query would optimise to be better, but the transport of the data across a network link would be slower. This was the second pass of this feature to optimise a system bottleneck identified by our customer - which originally used database queries.
Additionally, it's quicker to create three or four dictionaries than to install, design and query a SQL Express database when you've got a deadline.