为什么要说也呢？请参见http://www.sql-club.com/net2004/archive/2005/09/13/199.aspx
Partition一直就是一个很难用于实际应用的功能。为什么呢？选择分区字段是一个关键。必须要能使数据均匀的分散到不同的物理存储，又能使分区字段能够包含查询条件。
在smaple中大多是以ID或者Time作为分区字段，但是实际应用中，大部分查询都不会在这两个字段上。
以MSN为例，我登录的时候，要查询where username = 'luke@hotmail.com' --这不是我的passport
大部分的查询也是基于username的。
那么，我们以username为分区条件如何？可是这样会造成分区不均衡，显然s开头的就比x开头的要多许多。
当然，我们可以分析出字母序的分布概率，但是这是一个挺麻烦的工作，如果还考虑中文，就更加的麻烦了。
怎么办呢？MSN采用的方法是对username的hash值进行分区，值得借鉴哦~
hash的原理我不多介绍了，它有一个功能就是可以把字符串的hash值做到基本平均的分布。
SQL 2005自带一个hash函数，语法如下
HashBytes ( '
支持MD2, MD4, MD5, SHA, or SHA1 算法
返回值varbinary (maximum 8192 bytes)
打印 | 张贴于 2005-09-21 11:55:00 | Tag:暂无标签
留言反馈
MS China是MS China，MSN是MSN啦
MSN在上海的各个组里，我这个team适合你：全是SQL。而且我正在开始要做的就是一个financial reporting有关的部分。cube，replica，和BI有关吧~~~~
有兴趣就过来聊聊，美罗大厦12楼
SQL 2005的DPV有了一些改进，我做过一些测试，比SQL 2000要好。
不过没有做大规模的测试。
看哪个客户愿意做TAP了，明天去18楼跟客户聊聊看。
但根据Account ID来partition的一个比较头疼的问题是无法做到zero downtime upgrade。例如，想从4个SQL扩充到8个SQL，需要重新移动数据，不得不引入至少几个小时的downtime。
不过好在硬件发展的速度比数据增加的速度快，所以多年来一直没有实际遇到需要scale到更多box的情况。
用了partition以后，写stored procedure会受到一些限制。因为store procedure本身并不知道partition的情况，也不知道其他database被放在了哪个机器上，所以sproc里面必须紧紧处理它所在database里面的表和数据。
用view可以跨机器，不过不太经济。比较经济的是在代码一级（比如COM或者.NET）最靠近数据的一层处理partition。
对account进行partition都是horizontal partition。Vertial partition我这里不怎么用。与其vertial partition，还不如把数据库normalize一下。
以上作为对吕科的补充.