将会话数据存储在文件和数据库中的利弊是什么？
在搭建网站的时候，需要决定用户登录后，如何存储会话信息。
把每个会话存储在自己的文件里和存储在数据库里，各自有什么优缺点呢？
3 个回答
根据你之前的问题，我猜这个问题是关于使用Perl的CGI::Application模块，以及CGI::Application::Plugin::Session插件的。如果你用这个模块的默认设置，它会把会话数据存储在/tmp目录下的文件里，这和PHP的做法很像。如果你的应用在共享主机上运行，出于安全考虑，你可能不想这样做，因为其他用户可能会看到或修改/tmp里的数据。你可以通过把文件写入一个只有你有权限读写的目录来解决这个问题（也就是说，不要用/tmp）。在开发过程中，我更喜欢用YAML格式来存储数据，因为它更容易被人看懂，而不是默认的(storable)格式。如果你有自己的服务器，并且能在同一台机器上运行数据库（mysql）服务器，那么把会话数据存储在数据库里通常会更快，特别是当你能保持一个持续的数据库连接时（比如用mod_perl或fastcgi）。但是，如果你的数据库在远程主机上，每次更新会话数据都要重新连接，那么性能可能会变得更差，这时候写入文件可能会更好。值得注意的是，你也可以使用sqlite，它在你的应用里看起来像个数据库，但其实只是你本地文件系统上的一个文件。不管性能如何，在共享主机环境下，数据库选项可能不太合适，因为带宽和其他资源有限。对于流量不大的网站（比如每天几千次访问），性能差异可能也不明显。
Asp.net不支持把会话信息存储在文件里，不太确定Ruby on Rails（r-o-r）是否可以。不过，把会话信息存储在内存中（同一个进程里）比存储在数据库里要快。把会话信息放在数据库里可能会让你的应用更容易扩展（比如如果你想把应用部署在多个服务器上，所有服务器都可以访问同一个数据库来查找会话信息）。
这篇代码项目的文章对asp.net的会话管理提供了很好的见解。
我一般不会把这些信息存储在文件里，因为这样可能会导致文件在内存中来回切换（有时候可能会被缓存），但我更倾向于使用一种专门设计的内存机制，这样做比较不常见。
在ASP.Net中：
你可以使用内存集合，这种方式适合在单一服务器上使用。如果你需要多个负载均衡的网络服务器（也就是网络农场），而用户在每次请求时可能会访问任何一台服务器，这种方法就不太合适了。如果网络进程重启，之前的会话就会丢失，而且会话也可能会超时。
你可以在ASP.Net中使用状态服务器来支持多个服务器访问——这个服务器是独立于你的网络服务器进程运行的。如果网络进程重启，你的数据还是安全的，多个服务器都可以访问这个状态服务器。不过，发送到状态服务器的流量是没有加密的，最好在更安全的环境中使用IPSEC策略来保护这些流量。
你可以通过设置web.config来使用SQL Server自动管理会话，这样就能把SQL Server作为你的会话数据库。这种方式的好处是可以利用高性能的数据库，并且支持多服务器访问。
如果你需要会话在正常机制之外长时间保存，并且想对数据库字段有更严格的控制（比如你想查询特定字段），你可以在数据库中使用自己的会话。
另外，出于好奇，你是不是在说用户偏好设置的会话？如果是这样，可以研究一下ASP.Net的个人资料功能。