我目前正试图想出一个解决以下问题的方法:
我的任务是解析大型(+-3500行300kb)管道分隔的文本文件，并将它们逐行与我们数据库中的相应代码进行比较。一个文件的例子是:
文件名: 015_A.txt
文件内容(示例仅显示4行):
015|6999|Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old.|1|1|0|0|2016/01/01
015|3715|It has roots in a piece of classical Latin literature from 45 BC|1|1|213.5|213.5|2016/01/01
015|3724|Making it over 2000 years old.|1|1|617.4|617.4|2016/01/01
015|4028|Words will go here.|1|1|74|74|2016/01/01
我将提供一个web界面，我已经建立了允许从浏览器中选择一个文件，然后上传到服务器。
使用上面的示例管道文件，我将只使用这些:代码(以上面第1行为例:6999)
Price(以上面第1行为例:0)
然后我(我不确定这是否是最好的方法)需要为每一行运行查询(我们的DB是MSSQL)，例如:
SELECT t.Price
FROM table t
WHERE t.code = '6999'
如果t.Price === 0，则第1行已通过。因为它等于源文件。
这就是我相信我只需要问一些建议的地方，因为我确信有很多方法可以解决这个问题，我只是想，如果可能的话，以有效的方式指出做这件事的方向。(解析文件的最佳方法示例?我是对每个代码运行查询，还是使用IN子句执行SQL语句，然后比较每个代码和价格?我是否应该放弃这个想法，并使用某种形式的纯SQL工具(记住我有管道文件来处理/import)
你的故事似乎有点提前结束了。这个脚本应该做的唯一事情是检查数据库中的值是否与文件中的文件匹配?如果是这样，那么直接从数据库中提取数据并覆盖该文件会更简单。如果没有，那么这意味着您需要保留一些变量的记录。
这对和解的方法有一定的影响;对数据库运行3500个查询将花费一些时间——主要花在网络和查询解析上(即浪费)。OTOH在单个SELECT中比较3500条记录来查找不匹配根本不需要花费时间。
问题是你的数据在客户端，通过浏览器上传只能让它到达数据库的一半。如果您在数据库上创建另一个表(不是临时表-添加一列来表示文件)，则可以在单个DML语句中插入多行，但实际上您应该将它们批处理为100条左右的记录，这意味着您只需要执行36个查询来完成操作-并且您已经在数据库中获得了数据记录，从而简化了报告不匹配的方式。
你可能不应该使用DBMS提供的工具直接导入，除非你绝对信任源数据。