You should stick to using tables in SQL Server, rather than heaps that have no clustered index, unless you have well-considered reasons to choose heaps. However, there are uses for heaps in special circumstances, and it is useful to know what these uses are, and when you should avoid heaps. Uwe Ricken explains, and demonstrates why you'd be unwise to use heaps rather than tables when the data is liable to change.
In SQL Server, heaps are rightly treated with suspicion. Although there are rare cases where they perform well, they are likely to be the cause of poor performance. If a table is likely to have a large number of changes, then it can become fragmented due to way that space is allocated and forward pointers used. How does one detect this problem? Is it significant? How does one deal with it, if necessary? Neeraj Tripathi explains.