What's the problem?

I've avoided this because at some point I've needed to separate customers out. Either scale/size issues or regulatory problems.

I usually go with a separate database for each customer.

You can store data in a text/image column, but the max row size outside of that is fixed.

Don't cross post.

Answered here: http://www.sqlservercentral.com/Forums/Topic569582-8-1.aspx

a video here:

http://www.jumpstarttv.com/windows-and-sql-server-2005-clustering-architecture_31.aspx

Lots of resources on clustering if you search for them.

Red GAte (I work for them) has SQL Refactor, which will get them consistent, but it doesn't review code.

There's not anything that can review code to see if it's done...

I disagree. Clustering doesn't scale out at all. It provides redundancy, HA solutions, not scale out.

Polyserve (now HP) has an interesting solution.

Doh!, SSN, edited the post.

good advice above. Be sure that you don't need the 0 before you remove it. Some systems need it, or might be expecting xx digits, so...

Make sure you don't target any developers with that thing!

Thanks again for all the well wishes.

Phillip has a good idea. Assuming you're not using some of the things that don't work well with 64 bit (SQL Mail, etc.), looking at 64bit is a good idea....

Index rebuilds take time, they take resources and can lock things a bit.

In SQL 2005, there are more online operations (and 2008), so you can consider that. The other thing...

You haven't really described very well what you're doing.

Integration Services can handle over 1TB an hour of loads, so I might suggest you look at that.

Most of these tools assemble data from your tables into a format you can use. Unless you have extended properties on every fiekd, there isn't data that you can use...

Any edition of Windows that can handle 8GB of RAM is what you need.

You can run SQL enterprise on Windows standard. Not related.

Distributed Partitioned views, SOA techniques, all are available to build a scale out solution.

The reality is that most DBs do not scale out well. The solutions that have worked are...