I'm currently working on a project with a new requirement that, in a nutshell, queues submissions from users and submits them them to a remote API:
- collects submissions from users (with a form)
- each submission points to a record on a remote system (uuid provided by remote API)
- each submission has a status (ie: new, accepted, declined)
- each submission stores a number of other fields of data
- each submission references a node id that already exists in drupal
- submissions with a status of "new" are presented to an administrator, who can accept or decline them (the queue)
- changes to submissions are audited
- submissions are never published as content, as they may contain personal info
Much of the data being stored for each submission is simply for interaction with the remote API. Only a small amount of the data for each submission is for human/administrator eyeballs.
I began architecting the storage for these submissions - basically just a really wide database table with one column that references a node id. The database table will also need to be exposed in Views, so that I can easily build pagable, filterable & sortable html tables. Will also perform some custom bulk operations (View Bulk Operations).
I'm now debating if it would be wiser to use a custom node type with a pile of CCK fields to store these submissions as unpublished nodes, rather than building it all custom. On the downside, I'd have to do a lot of form_altering to get the submissions form to where I want it, and I really don't need a lot of node functionality (workflow, comments, titles, etc, etc). On the plus side, if using nodes+cck the Views integration comes for free, and it's likely quicker to build.
I'm working in Drupal 6, and an upgrade to Drupal 7 is at least a year out - but it's also something I need to consider when making this decision.