在数据库中执行重复更新的性能指南
我有一个数据库表，其中一个字段包含 RTF（富文本格式）。我需要将 RTF 转换为 HTML，以便稍后在 HTML 编辑器中正确显示它。
为了实现这一目标，我开发了一个控制台应用程序，它为每个表条目读取 RTF 字段并将其转换为 HTML。此步骤只需执行一次（这是一个独特的迁移过程），大约有1500 条记录受到影响。
由于涉及的记录数量不是那么高，性能不会受到太大影响，但暂时忽略数据量，我想知道哪种模式是这种场景的最佳模式：
1) Extract data from DB<br>
2) Execute modification on that data<br>
3) Update the relative row with modified values
考虑到我正在使用 LINQ to SQL ，仍然可以接受为每个修改的记录执行一个submit()，还是将修改的记录存储在数据结构中（例如带有ID、modifiedValue的HashTable）并为所有记录创建一个submit()会更好？
I have a database table with a field containing RTF (Rich text Format). I need to convert RTF to HTML in order to proper display it later in a HTML Editor.
To achieve this I developed a console application that for each table entry reads the RTF field and convert it to HTML. This step would be done just once (is a unique migration process) and there are around 1500 records affected.
Since the number of records involved is not so hight, performance will not be deeeply affected, but ignoring for the moment the data volume I would like to know which would be the best pattern for this kind of scenarios:
1) Extract data from DB<br>
2) Execute modification on that data<br>
3) Update the relative row with modified values
Considering I am using LINQ to SQL, is still acceptable execute a submit() for each modified record or would it be better to store the modified records in a data stracture (like HashTable with ID, modifiedValue) and make a single submit() for all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
DBMS 的性能通常按以下顺序受硬件影响：
在软件方面，瓶颈通常至少是其中之一，不一定按此顺序，影响范围可以从第一个开始到上面列表中的最后一项：
您的算法很简单，并且 - 假设您有一个主键并且它只是一个表 - 您无法从索引或查询计划中获益。
你提到这是一次性的事情，所以我开始将所有内容放入一笔交易中。
如果您的 DBMS 是 Microsoft SQL Server 2005 或更高版本，您可以使用 CLR 集成 并消除硬件边界号 1。
Performance on DBMS is usually affected by hardware in this order:
On the software side, the bottleneck usually is at least one of these, not necessarily in this order, and effects can range from the first to the last in the above list:
Your algorithm is simple, and - assuming you have a primary key and it is just one table - you cannot gain from indexes or query plan.
You mention this is a one off thing, so I'd start putting everything into one transaction.
If your DBMS is Microsoft SQL Server 2005 or up, you could run the whole thing on the server itself using CLR Integration and eliminate the hardware boundary number 1.