本文发表在 rolia.net 枫下论坛我假定我们是在data model design的层面讨论,也就是通常designer和DBA的角度。Clustered index显式定义数据的存储顺序,或者说,override数据库的决定,经常是错误的。大方向上说,数据的物理存储顺序应该是数据库根据逻辑model决定的,而不是model这一层所关心的。具体的说,需要clustered index经常是以下几种错误:
1. 画蛇添足。不同的数据库根据自己的implementation,大多数情况下,能够推断出正确的存储顺序。比如,有primary key的用primary key,没有primary key的,再看unique index,等等。如果你的定义和数据库的选择是一样的,不仅仅是无用功,更是影响移植性和以后数据库升级,因为你现在的选择再以后的版本就不一定正确了。
2. model本身有问题。在数据库没法正确推断的时候,经常是“it doesn't matter"。比如,多对多的关系表,两边的foreign key当然要index了,但是有没有必要非要定义个clustered index呢?我还真没碰到过。如果“it matters”,很可能是model有问题了。
3. 解决不了问题。我上面提到过传统的OLAP,主要是star schema的fact tables,经常是denormalized,index很多,但是没有unique的。这时,clustered index是最naive的"办法“,但是解决不了问题。比如,有5个常用的dimension index,你选哪一个都不够。data warehouse的产品都是用别的办法解决的。更多精彩文章及讨论,请光临枫下论坛 rolia.net
1. 画蛇添足。不同的数据库根据自己的implementation,大多数情况下,能够推断出正确的存储顺序。比如,有primary key的用primary key,没有primary key的,再看unique index,等等。如果你的定义和数据库的选择是一样的,不仅仅是无用功,更是影响移植性和以后数据库升级,因为你现在的选择再以后的版本就不一定正确了。
2. model本身有问题。在数据库没法正确推断的时候,经常是“it doesn't matter"。比如,多对多的关系表,两边的foreign key当然要index了,但是有没有必要非要定义个clustered index呢?我还真没碰到过。如果“it matters”,很可能是model有问题了。
3. 解决不了问题。我上面提到过传统的OLAP,主要是star schema的fact tables,经常是denormalized,index很多,但是没有unique的。这时,clustered index是最naive的"办法“,但是解决不了问题。比如,有5个常用的dimension index,你选哪一个都不够。data warehouse的产品都是用别的办法解决的。更多精彩文章及讨论,请光临枫下论坛 rolia.net