I really don't think it is the number of partitions that really matter in this case, more of how you're using them. If you're always accessing your data based...

Of course, if you're partitioning by date (the way it was really intended), and you always include a date in the predicate, the benefits of partitioning would likely outweigh the...

Its actually not as much of a benefit as you'd expect. You'd always have to include your partitioning key in your predicate so that SQL is able to identify...

Solomon is correct. Partitioning is NOT intended to increase query performance, it is intended to increase data manageability and administration. SQL 2008 did some things to make better...

Yep, makes sense. The when using the OR clause the QO has a hard time using indexes as intended. Using ISNULL() or COALESCE() is even worse (worse because...

Nice article, Jacob.

In terms of performance, there should be no difference between EXEC and sp_executesql when no parameters are used. When params are used with sp_executesql, its...

I wrote an article for SQL Mag not too long ago (sadly hasn't published yet) about the differences between the two versions. Have also had several talks w/ the...

Hi Paul,

To be honest, the performance aspect of 2008 isn't much (if any) better than 2005.

SQL Guru,

I suspect I know what you are referring to. 😀

Tim

SQL Server MVP

Nice article Solomon, BTW. 🙂

Hi alen,

Be careful before you decide to employ partitioning here. Do whatever you can do test your queries before you decide to implement. It could be a...

In SQL 2005, it has been my experience that parsing an XML data type using XQuery is more resource intensive than other methods.

You can pass table valued parameters in SQL 2008...

http://blogs.techrepublic.com.com/datacenter/?p=168

At this point, it doesn't make a whole lot of sense to me to be set on data types, or indexes. You don't know for sure how it is...

For #6, you can also change the execution context of the trigger to execute as the execution context you need.