我要更新一个大表，270更新领域。

I have to update a big table with over 270 update fields.

我相对新到.NET和需要提醒的是更好地在这种情况下使用：SqlCommand的，某种存储器映射表或数据集或者它存在某种自动生成的对象，使用从DB中的元数据？请大家帮帮忙。

I am relative new to .NET and need advise what is better to use in this case: SqlCommand, some kind of memory-mapped table or DataSet or maybe it exists some kind of auto-generated objects using meta-data from DB? Please help.

原因： 我有一个旧的大Delphi7的应用程序，其中有一部分是负责监听套接字某些数据包这是封送到大的结构，并在最后一步，存储在数据库中。现在我移植这部分新的C＃服务，实际上，至少我有preserve相同的逻辑。 问题是，结构大（超过220场），并保存它的表有近300场。从我的220场结构扣除/计算等〜50场，所有应该更新的数据库。 实际德尔福code是丑陋的蚂蚁它的增长在数年如表本身，是这样的：

Reason: I have an old big Delphi7 application, a part of which is responsible for listening on socket some packets which are marshaled to big structures and, in final step, stored in DB. Now I am porting this part to new C# Service and at least actually i have to preserve the same logic. The problem is that structure is BIG (over 220 fields) and tables where it is stored have near 300 fields. From my structure of 220 fields are deducted/calculated other ~50 fields and all should be update in DB. Actual Delphi code is ugly ant it grew over several years like table itself, something like this:

'UPDATE TABLE_NAME ' +
  '  MSG_TYPE = ' + IntToStr(integer(RecvSruct.MSG_TYPE)) + ' ' + 
  ' ,SomeFLOATfield = ' + FloatToStr(RecvSruct.SomeFLOATfield) + ' ' + 
  ... //and other over 270 fileds here
'WHERE ID = ' + IntToStr(obj.ID)

没有任何动态SQL等。 其实我不能改变数据库结构..所以，我必须只在code玩，我不知道，如果它是有针对性地来翻译code。表是用于一些报告和统计。一些计算/扣除领域必须处理的源 - code一些常量。

no any dynamic SQL, etc.. Actually I cannot change DB structure.. so that i have to play in code only and I am not sure if it is pertinently to translate code. Table is used for some reports and statistics. Some of calculated/deducted fields have to deal with some constants in source-code.

用于DEV-工具： MS SQL Server 2000中，C＃.net2.0，VS2008

used dev-tools: MS SQL Server 2000, C# .net2.0, VS2008

推荐答案

最简单的解决方案，适用于这里，因为这样OLE DB的作品是字符串。所以，通过270，500，1000的参数，我要做的就是传递一个字符串，包含270参数字符串可能是远低于2KB ......这在现代计算......结转的1 ...不有性能损失。这里有一个XML解决方案在这里，但是这只是苹果和橘子，你仍然传递字符串，这将需要额外的code不过来处理XML。所以......你的架构应该是这样的：

The simplest solution applies here because the way ole db works is with strings. So, to pass 270, 500, 1000 parameters, all I do is pass a single string, a string containing 270 parameters is probably well under 2kb... which in modern computing... carry over the 1... doesn't have a performance penalty. There's an xml solution here, but that's just apples and oranges, you're still passing the string, it would require extra code to handle the xml however. So... your architecture should look like:

SQL Server上的存储过程与270的输入参数：

Stored procedure on SQL server with 270 input parameters:

 Create Procedure sp_Example1 
 (@param1 [type], @param2 [type], @param3 [type], etc...)
 AS 
 BEGIN
 [SQL statements]
 END

270参数的命令对象：

A command object with 270 parameters:

SqlCommand cmd = new SqlCommand("sp_Example1", [sqlconnectionstring]);
cmd.Parameters.Add(New SqlParameter("@param1", param1.value));
cmd.Parameters.Add(New SqlParameter("@param2", param2.value));
cmd.Parameters.Add(New SqlParameter("@param3", param3.value));

记住，你仍然做了pretty的集约化经营，但你的基准应该是旧的应用程序。如果它是差那么一点点，我就不会担心，因为框架需要更多的计算开销。

Remember, you're still doing a pretty intensive operation, but your benchmark should be the old application. If it's a little bit worse, I wouldn't worry about it, since the framework requires more computing overhead.

我不知道为什么它不会格式化code ...

I have no idea why it won't format the code...