关于产品表分类设计读取的性能问题

Question

有两种情况。第一种比较简单，两个表：
1.产品表
2.分类表
在产品表中存放分类ID.分类约20个分类，产品总数约2W，每页显示20个
我在读取某个分类列表的时候需要显示产品所属的分类，那么现在有两种方法读取：
第一种方法：将分类表用泛型集合类缓存。在repeater绑定产品列表时，在item_databound事件中根据分类ID去读取分类名。
第二种方法：left join方法同时读取两个表。返回内容直接绑定。说明：第一种方法将分类缓存了，在读取时还得去泛型集合类中查找分类名，不知道这个损耗时间如何。因为对item_databound事件的具体执行原理不太懂。那么请问：
一。第一种方法中读取分类名是每绑定一条记录就要去查找一次还是有其它读取方法？
二。根据现实情况。这两种方法哪种效率最高？第二大问题：
假如扩展到三个表
1.产品表   2，分类表   3。商家表
在读取产品时同时要显示产品所属分类和所属商家，该如何设计这几个表结构和读取？一定得用left join吗？   问题很急。请高手们帮忙回答。谢谢

Answer 1

建议用后者。item_databound非常耗时，当初用UltGRID时遇到类似情况。每一行数据要在一组时筛选内容再绑定。很麻烦。可以和联接读完后放在一个带分类及商家的商品构造构数内。即商品实体类可以重载一个方法，里面包含类别与商家信息

Answer 2

说明：第一种方法将分类缓存了，在读取时还得去泛型集合类中查找分类名，不知道这个损耗时间如何。因为对item_databound事件的具体执行原理不太懂。那么请问：
一。第一种方法中读取分类名是每绑定一条记录就要去查找一次还是有其它读取方法？
二。根据现实情况。这两种方法哪种效率最高？
--------------------------------
一。不需要每次都去查找，使用hashtable可以大大减少查找时间。 类型的ID作为hashtable的Key，类型的名称作为hashtable的Value。这样效率很搞，不用去遍历。
二。因为你的产品表才2W条数据，分类表也非常小，所以我觉得不用考虑你说的缓存产品分类的做法，两个方法的效率不会有很显著的效率上的差别。之所以不推荐缓存产品分类，是因为实际项目中很少有人这么去做，也不是说不能做，你要做也完全可以，但是感觉没有必要。

Answer 3

第二大问题：
假如扩展到三个表
1.产品表 2，分类表 3。商家表
在读取产品时同时要显示产品所属分类和所属商家，该如何设计这几个表结构和读取？一定得用left join吗？
------------------------------------------------------
没有什么事情是一定的。你这里主要肯定还是怕left join的性能上可能不如你去缓存。 我感肯定的说，你这个性能差距绝对非常小，正常人完全不可能感觉出来。 使用缓存会导致你的代码量增加，后期维护我觉得是个问题，而且也不利于你在数据库设计阶段的工作，因为你设计数据库的时候需要考虑这个分类要不要呢？？是不是做缓存算了？？
现在主流的数据库是关系型数据库，一般也都这么设计。left join，只要不是你索引建立得非常烂或者数据表十分庞大，性能上非常的OK！！！！ 对于你这中几万、几十万条数据来说真的是不算什么。
所以，最后的回答是，分类和商家都有自己独立表，和产品表有一些外键依赖关系(具体什么关系看你自己的分析)，查找数据的时候用join去取这些数据。一般不用缓存(也有使用缓存的时候，这里不必要)。

Answer 4

另外，比如表太大了，而且你的类型表非常的稳定，在设计阶段就有可能设计为把类型名称直接写入到产品表里面去，这样可以避免一次join操作。但是就你这里的情况来说，还是就按照正常的设计来走。
性能上，你完全没有必要担心。当然，你自己感兴趣的话，可以做个性能测试。呵呵。

Answer 5

一般不用join 要读取到那些数据时再通过点击去读取

Answer 6

非常感谢楼上的朋友。特别感谢zsuswy，我就是担心将来数据量如果扩展到很大。比如50W以上的时候。用left join会严重影响性能。我到时候会去做个测试。

Answer 7

你去试一下，索引要建立好，100W以下的数据，你Select出来几十条，速度完全没有问题。当然，你select * from 一下取出全部数据，那肯定是慢，那么多数据你直接从硬盘读都慢。。