<p>Given a small set of entities (say, 10 or fewer) to insert, delete, or update in an application, what is the best way to perform the necessary database operations? Should multiple queries be issued, one for each entity to be affected? Or should some sort of XML construct that can be parsed by the database engine be used, so that only one command needs to be issued?</p>

<p>I ask this because a common pattern at my current shop seems to be to format up an XML document containing all the changes, then send that string to the database to be processed by the database engine's XML functionality. However, using XML in this way seems rather cumbersome given the simple nature of the task to be performed.</p>

[{'answer_id': 44474, 'author': 'jodonnell', 'author_id': 4223, 'author_profile': 'https://Stackoverflow.com/users/4223', 'pm_score': 0, 'selected': False, 'text': '<p>Most databases support BULK UPDATE or BULK DELETE operations.  </p>\n'}, {'answer_id': 44477, 'author': 'VanOrman', 'author_id': 4550, 'author_profile': 'https://Stackoverflow.com/users/4550', 'pm_score': 1, 'selected': False, 'text': '<p>You didn\'t mention what database you are using, but in SQL Server 2008, you can use table variables to pass complex data like this to a stored procedure.  Parse it there and perform your operations.  For more info, see Scott Allen\'s article on <a href="http://www.odetocode.com/articles/365.aspx" rel="nofollow noreferrer">ode to code</a>.</p>\n'}, {'answer_id': 44478, 'author': 'Guy Starbuck', 'author_id': 2194, 'author_profile': 'https://Stackoverflow.com/users/2194', 'pm_score': 0, 'selected': False, 'text': '<p>From a "business entity" design standpoint, if you are doing different operations on each of a set of entities, you should have each entity handle its own persistence.</p>\n\n<p>If there are common batch activities (like "delete all older than x date", for instance), I would write a static method on a collection class that executes the batch update or delete.  I generally let entities handle their own inserts atomically.</p>\n'}, {'answer_id': 44479, 'author': 'Andrew', 'author_id': 826, 'author_profile': 'https://Stackoverflow.com/users/826', 'pm_score': 0, 'selected': False, 'text': "<p>The answer depends on the volume of data you're talking about. If you've got a fairly small set of records in memory that you need to synchronise back to disk then multiple queries is probably appropriate. If it's a larger set of data you need to look at other options.</p>\n\n<p>I recently had to implement a mechanism where an external data feed gave me ~17,000 rows of dta that I needed to synchronise with a local table. The solution I chose there was to load the external data into a staging table and call a stored proc that did the synchronisation completely within the database.</p>\n"}, {'answer_id': 44482, 'author': 'Eric Z Beard', 'author_id': 1219, 'author_profile': 'https://Stackoverflow.com/users/1219', 'pm_score': 2, 'selected': True, 'text': "<p>It depends on how many you need to do, and how fast the operations need to run.  If it's only a few, then doing them one at a time with whatever mechanism you have for doing single operations will work fine.</p>\n\n<p>If you need to do thousands or more, and it needs to run quickly, you should re-use the connection and command, changing the arguments for the parameters to the query during each iteration.  This will minimize resource usage.  You don't want to re-create the connection and command for each operation.</p>\n"}]
['https://Stackoverflow.com/questions/44469', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/767/']