是否值得在ASP.net中为外键值缓存一个字典?

时间:2010-04-10 03:22:00

标签: asp.net database

我有一个Dictionary<int, string>缓存(持续20分钟),参数表有大约120个ID /名称对。我在填充下拉列表时迭代这个集合,我很确定这比每次查询完整列表的数据库要快。

我的问题更多的是关于在将具有外键的记录显示到此引用表中时是否有意义使用此缓存字典。

假设此缓存的引用表是EmployeeType表。如果我查询并显示员工姓名和类型的列表,我应查询EmployeeName和EmployeeTypeID,并使用我的缓存字典在显示每条记录时获取EmployeeTypeIDs名称,或者让DB抓住EmployeeName和JOIN更快获取EmployeeType字符串,一起绕过缓存的字典。

我知道两者都会奏效,但我对最快的表现感兴趣。谢谢你的帮助。

2 个答案:

答案 0 :(得分:2)

我知道你不会喜欢这个答案,但常识要求你做最简单的事情,如果太慢,那么你就可以采取补救措施。

我会解释自己。事实上,如果你对它进行缓存,它可能会更快,因为每次加载页面时都不会访问数据库,但是你所做的事情可能并不明显(即你可能有一些其他瓶颈使得收益微不足道),首先打败了缓存的目的。

唯一的方法,就是以最简单的方式(没有缓存)做到这一点,如果你不开心,那么你就会额外付出代价。

答案 1 :(得分:2)

优化101说不要这样做,除非你需要: - Tips for optimizing C#/.NET programs

但是,是的,如果这真的是一个完全静态的查找应用程序的生命周期并且它占用非常少的RAM然后缓存它看起来相当无害而且从RAM中查找字典会比访问数据库更快

至于第二部分你也可以让数据库进行连接,它可能已经在RAM中拥有该表,并且增加的网络负载看起来很小。

但是,如果你不需要这样做,不要这样做!这里的危险是你做了这个,然后是另一个,然后是另一个,代码变得越来越复杂,RAM填满了你认为可能需要的东西但实际上很少用于为OS / ORM / DB留下更少的空间做它的工作。让编译器,ORM和数据库决定在内存中保留什么 - 他们有一个更大的团队专注于优化!