Using IN queries or joining to a temporary table inside views for data managers to use with VBO for one-off updates Our data managers routinely analyze Drupal content in external mapping and analysis programs and generate lists of nodes that require updates.  I'm looking for a solution that will allow them to update this arbitrary list of nids, preferably within a friendly UI.

Background

We've recently migrated from a custom database application to Drupal.  In the past our data managers would perform a sql in query (SELECT * FROM table WHERE ID IN (27, 83, 99, ....)) or upload a temporary table to the database, do a join and perform updates.  I'm looking for a way for them to do the same thing, but inside of Drupal so the proper update hooks are fired.  

So far my Google skills and searches on drupal.org are failing me.  It seems this should be a common problem?  Is there a best practice when performing these sorts of one-off query/updates?

Some related solutions I've considered


Views contextual filters using either default arguments or arguments in the url (Create a view from specific Node ID&#39;s) - This is limited to only a few dozen nid's as a default argument or maximum url length.  Not suitable for long lists of nid's
Researched using Node Queue with the solution above but the UI doesn't seem to allow bulk adding of nodes, but perhaps I'm overlooking something.
Custom module to expose a table to views (Join a custom table on a View) - not ideal since requires programming every time a new update needs to be performed
Write a custom query and update to perform IN queries (Using IN clause in db_query) - again requires code, which I'm not opposed to if I can work up a reusable solution that our data managers (not programmers) can use to maintain our data.


An ideal solution would be a fiter criteria that allowed our data managers to paste a long csv string.  Something like "In list" which operates similar to the "Is between" functionality. 

I'm overlooking something obvious! Ideas?
You could try Feeds as well .... but ...

Use either a CSV file or one of its other Migrate Sources, for instance it can use another database table as your source of change-data. But I recommend the Migrate module.

Your CSV can hold the primary key and whatever fields you need to update. You could use the new hash() functionality in Migrate 2.6 to check for changes in your data so that content is either Updated or Inserted as needed.