Question

SQL数据库架构问题

例如：有一张商品信息的基表，Product 里面存着一些商品的信息，售价，等等。。。
现在要 储存 超市里这些商品的信息，因为各个超市的商品售价不一定相同，所以要单独储存超市商品的信息，我新建一张超市商品信息表ShopProduct，这里面有超市的编号，商品的编号，售价，等一些字段。
现在问题来了， 假设有500家超市，每家超市有1万种商品的话，ShopProduct表里就会有500万条数据，如果超市无限增多的时候，ShopProduct表的数据会无限增大
那查询的效率会非常的慢，这种表该如何优化呢？
或者该如何构建这个数据库结构呢？
如果每家超市做一张表的话 那数据库会有N多表，也不太现实吧？有没有更好的办法呢？如果问题解决的话 再加20分

Answer 1

分区表, 可能可以解决一部分问题.
也就是 按 超市的编号 进行分区管理.
这样, 假设有500家超市，每家超市有1万种商品的话
ShopProduct表 有 500 个分区, 每个分区 1万种商品.

每个超市,检索其 自己的数据的时候, 肯定要 传入 超市编号 这个字段的.
当数据库分析 SQL 语句的时候，会分析要， 对于这个 指定的超市的编号， 我需要去哪一个分区去检索。 知道去哪一个分区去检索的话， 范围就被局限在 这 1万种商品范围内。 不会去查询其他超市的数据。

缺点也有一点， 就是每新建一个超市， 要在数据库上面创建一个新的分区。
还有就是，假如你不传递任何 超市的条件， 仅仅通过 商品的编号 去查询这个商品， 在各个超市的 售价， 那么，查询性能可能会比较低。

追问

如果分区的话 效率肯定会有一定的影响吧？
对于这种情况
如果我每添加一个超市 创建一张视图的话 然后有一张表储存着每家超市的视图名称，
根据视图名称去查询该视图~ 这样效率是不是快一些？
但是这样 会造成有N多视图， 对于这种情况
是建视图好呢 还是建分区好呢？

追答

简单地创建个视图,并不会提高你的查询效率的啊. 因为视图最后也还是执行一个 SQL语句。
如果只需要建立一个表的话。
500家超市，每家超市有1万种商品，也就500万条记录。
把索引规划好，也是可以满足基本的查询操作的，不一定要拆分区表。
因为你这个相当于是商品字典表的性质，终究有个上限值。
不是销售数据表，数据量那是无限增加的。

500W的数据，普通表简单处理，也是可以的。不必分区处理了。
一个复合索引规划好就行。
也就是基于 超市编号,商品编号，创建一个唯一索引，检索速度不慢的。

追问

500W条 记录也不算多 我怕以后添加了 500W家超市 这个表该怎么查询 速度会快~
查的时候只会根据 商品编号和超市编号 两个 列来查，
最多有个 根据商品编号查出每个超市的售价

追答

我这里 SQL Server 分区表的例子，暂时没有。

SQL Server 分区视图的例子，你可以参考参考看看。

http://hi.baidu.com/wangzhiqing999/blog/item/8890128f76ec08c4fc1f101d.html

Answer 2

如果真有500家超市，每家有1万种商品，可以把产品分20类，建立20个不同 Product表，和20个不同的ShopProduct表。
如果超市继续增加，可以继续细分产品类别。

Answer 3

有一个观点我不认可：应该是超市放在Shop表里，商品信息放在Product表里，而ShopProduct表只记录前两个表中数据的对应关系，这样比较合理吧；
可以考虑用分区表，或者可以考虑把ShopProduct按地区分为几个表（如东北地区、华北、西北等）

追问

是啊 本身就有一个shop表 我说的 ShopProduct 里存有 超市的编号，商品的编号，售价，
超市本身就有一个超市的信息表 存超市的编号，名称等待。。。
问题是这个对应关系是很多的，1W件商品 500家超市， 500家 超市都卖这1W件商品 但价格不同 那就得有 500W条对应关系吧？ 如果再增加500家超市 就是1000W个对应关系了