假定现在有这样一个问题，界面上有两个Grid数据网格，左边的用来显示在校学生的基本信息，右边显示的是左边某选中的学生的历年成绩。这样一个简单的问题，怎么来设计一个高效的数据解决方案。
这个问题很简单的，有人可能就这样说了：在左边Grid的单击或选中改变事件下，到成绩表中根据学号查此人历年成绩不就行了。事实上我也见过有人这样写，但稍有头脑的开发员都会杜绝此类操作。很简单，这样无异于把数据库服务器逼上了绝路。请求太过频繁了，服务器的压力太大了！一般的开发员会这样处理：在界面初始化的时候就把成绩表中的全部数据查到客户机的内存里，再根据左边选择的改变来操作内存中的数据。这样既减小了服务器的压力，又提高了效率，因为直接从本地内存中检索数据的速度是很迅速的。但这样操作还是很有隐患的，随着数据量的增加，成绩表中的数据可能就变成了巨大的海量数据，本地的内存能否够用呢。再者一下涌入大量数据把内存占满，也会造成处理效率降低甚至会更严重。想了一下，只想到了很蹩脚的方法。首先，从网络方面下手，服务器的负载均衡，服务器的合理集群就会有非常好的降压分流作用，况且横向扩展的方案要比纵向提升服务器档次的方法代价小的多。再有就是数据库结构设计，从表也就是上面的成绩表，要有索引，这样才更有利于高效的查询。从程序开发角度，假定成绩表的数据量已经非常巨大了，本地内存根本满足不了，我会这样做：先筛选某段学号的成绩(以最大限度使用本地内存为限)，因有索引，这段查询的效率基本不会受影响，查到本地内存。根据左侧的学号查询成绩时，先查本地的内存中是否存在，如不存在，再发送查询语句到服务器查询，查询后的数据可追加到内存中保存，也可用后直接释放以节省内存。因大部分的数据已经提前取到本地，再次请求的可能就会很小，即使再次请求，如果对服务器进行合理布局，也基本不会造成效率上的影响。 但是这种大数据量的情况一般不会出现，因为这种情况下一般都对主表进行了分段管理，如对学生按年级或班级，或者按时间段划分。这样从表的数据检索量就大大减少了，自然不会出现海量数据问题，再者对历史数据的备份和归档也会减少当前的数据量。所以只有狂想一下喽。
