关于表的主键及聚集索引建立问题
表结构如下：
ID      标识、自增为1
date    日期
name    名称
number  数量

大致内容如下：
ID     date        name    number
1      2013-3-7    衣服      10
2      2013-3-7    裤子      5
3      2013-3-7    帽子      2
4      2013-3-8    衣服      3
5      2013-3-8    帽子      20
6      2013-3-8    袜子      50
*
*
特点
1、还有其他字段，比如店铺、规格、单位、单价、总价等。
2、每天都需要添加3000条记录，一直不停地往下添加。
3、品种（也就是name）是基本确定的，大概200个左右。


1、我的想法是ID为主键、自增为1
2、聚集索引建立在date上；因为查询时，日期肯定为第一要素。
3、店铺、品种为非聚集索引；因为要做比较细致的查询时，这两个字段是用频率比较高。
请问这样科学吗？

突然异想天开地想着设置ID+date为复合主键，date为聚集索引。
相比我自己的方案，哪个好一些？
分不多，请大神别介意，指点指点。
------解决方案--------------------
一般讲像自增id这类的顺序、递增、选择性高的列适合聚集索引
但是你条件基本没用id查询，所以也就不要给它了
聚集索引倒是可以用date+名称，然后include(number)
如果你的name、店铺、等其他列也有单独查询的现象，可以单独或看情况添加复合索引
------解决方案--------------------
Date+name聚集主键（如果唯一）
店铺非聚集

如果需要，根据选择字段设置include

------解决方案--------------------
过早考虑优化，先把功能建立起来再说，不要低估SQL的处理能力，也不要高估索引的作用。

聚集：日期+名称+店铺
一点也不宽，除非字段定义得太离谱。如果规范化设计也就几个字节，个人认为应该规范化。

非聚集：名称+店铺+number 和 店铺+名称+number
统计用的，根据主要统计字段选一或全选。普通的select派不上用场，因为选择性太差。

------解决方案--------------------
我倒觉得应该在设计的时候就考虑性能问题，当然前提是要先满足业务需求，不然其他都是白搭，对于索引，我个人觉得先要知道如何用这个表，才去考虑如何建索引，如果整表加载，那么没索引更快，如果是查询某些数据，那有索引往往更好，所以我一般是先等开发写好语句后再整体去衡量如何建索引
------解决方案--------------------

引用:

我倒觉得应该在设计的时候就考虑性能问题，当然前提是要先满足业务需求，不然其他都是白搭，对于索引，我个人觉得先要知道如何用这个表，才去考虑如何建索引，如果整表加载，那么没索引更快，如果是查询某些数据，那有索引往往更好，所以我一般是先等开发写好语句后再整体去衡量如何建索引

你这就不属于过早优化了，LZ的情况我不认为已经到了开发阶段，数据库建模阶段都谈不上。
------解决方案--------------------
1、我的想法是ID为主键、自增为1
2、聚集索引建立在date上；因为查询时，日期肯定为第一要素。
3、店铺、品种为非聚集索引；因为要做比较细致的查询时，这两个字段是用频率比较高。
请问这样科学吗？

挺好的