Winform 中的 Datareader 或 Dataset 需要长时间访问数据库？
我有一个将在美国和中国使用的 Winform 应用程序。 SQL Server 2005数据库位于美国，因此中国人的数据访问速度会较慢。 我正在决定使用 DataReader 和 Dataset 以获得最佳性能。 检索后，数据将立即加载到业务对象中。
问题：从远处的数据库中提取数据时，哪一个（DataReader/DataSet）性能更好？ 我读到 DataReader 每次 .Read() 都会返回数据库，因此如果连接一开始很慢，那么 DataSet 是否是更好的选择？
谢谢
I've got a Winform app that will be used in the US and China. The SQL Server 2005 database is in the US, so the data access is going to be slower for the people in China. I'm deciding between using a DataReader and a Dataset for best performance. The data will immediately be loaded into business objects upon retrieval.
Question: Which performs better (DataReader/DataSet) pulling data from a database that's far away? I have read that the DataReader goes back to the database for each .Read(), so if the connection is slow to begin with, will the DataSet be a better choice here?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您期望长距离/慢速链接，则与数据库往返相比，数据读取器与数据集的性能几乎无法衡量。
不过，数据集可能会使用更多内存，如果您正在处理大量数据，这可能会是一个问题。
The performance of datareader vs a dataset will barely be measurable compared to the database roundtrips if you're expecting long distance/slow links.
DataSets might use more memory though, which might be a concern if you're dealing with a lot of data.
取决于数据量。 你不能在内存（数据集）中存储太多的数据。
我认为有两种方法可以解决你的问题：
- 并行化（System.Thread）
- backgroundworkers
第一个可以提高 linq to sql 情况下的性能。 第二个可以帮助最终用户获得更好的体验（非 bloqued UI）。
depend of amount of data. You cannot store in memory (dataset) a too large amount.
Two ways for your problem at my mind :
- parallelisation (System.Thread)
- backgroundworkers
The first can improve performance in linq to sql cases. The second can help end users have a better experience (non bloqued UI).
我认为这没关系，因为连接是瓶颈。
两者都使用相同的机制来获取数据（ADO.NET/Datareader）。
如果可以的话，您可以在服务器上压缩查询结果，然后将其发送到客户端。 这会提高性能。
I think it doesn't matter since the connection is the bottleneck.
Both use the same mechanism to fetch the data (ADO.NET/Datareader).
If you can do it you might compress the query result on the server en THEN send it to the client. That would improve performance.
要看是什么数据库。 如果是Access的话情况就不好了。
取决于移动的数据量，使用方式是什么？ 中国的用户会直接读取公共数据还是进行读/写操作？ 他们需要查看所有数据吗？
这个想法是，分离数据（如果它有助于场景）并将其合并回来。
Depends on what database it is. Bad situation if it is Access.
Depends on how much data is moved around, what is the usage style? will users from China just read or do read/write on common data? do they need to see all data?
The idea is, separate the data (if it helps the scenario) and merge it back.
选择哪个并不重要，因为 DataSet 使用 DataReader 来填充。 通过缓存结果或获取额外数据，尽可能避免调用数据库。 一些获得额外数据的调用可能会胜过桌上的许多小啄。 也许BackgroundWorker 可以预加载一些您知道将要使用的数据。
It doesn't matter which you choose since the DataSet uses the DataReader to fill. Try to avoid calling the db whereever possible, by caching results or by getting extra data. A few calls that get extra data will probably outperform alot of small pecks at the tables. Maybe a BackgroundWorker could preload some data that you know you will be using.
对于其他读者来说：DataReader 的性能要高得多。 显然，这些用户没有尝试使用两者并实际测试过差异。 使用 DataReader 加载 1,000 条记录，使用 DataSet 加载 1,000 条记录。 然后尝试将 DataSet 的记录限制为 10 条记录（使用适配器的 Fill 方法，以便加载 1,000 条记录，但只有 10 条填充/填充到 DataSet 中）。
我真的不知道为什么数据集在填充操作期间性能如此糟糕，但差异是巨大的。 创建自己的集合并用 DataReader 填充它们比使用非常臃肿且缓慢的 DataSet 要快得多。
Just for other readers: the DataReader is MUCH more performant. Obviously, these users have not tried using both and actually tested the difference. Load 1,000 records with a DataReader and 1,000 with a DataSet. Then try limiting the records for the DataSet to 10 records (using the adapter's Fill method so that the 1,000 are loaded, but only 10 are populated/filled into the DataSet).
I really don't know why DataSets are so bad performance-wise during the fill operation, but the difference is huge. Its much faster to create your own collection and fill them with a DataReader than use the very bloated and slow DataSet.