Multiple App Instances, Multiple DBs or Interconnected Tables?

I am extending an e-voting application with a database. Consider multiple concurrent ballots. For each ballot, several configuration options are stored, and also the votes.

The configuration tables are obviously very small, in the presence of a reasonable amount of concurrent ballots, but the votes table can grow to be extremely large.

My question is this: is it better to hav开发者_如何学Goe the DB concern only one ballot, and have each ballot create a new instance of the whole DB, or to have a ballot_id foreign key in most tables, and store the data for all ballots in the same DB?

My question mainly concerns performance, especially of insertions in the votes table, once it has grown to be huge.

---

My rule of thumb -- keep it in the same DB and use partitioning to manage tables. Using partitioning, you can move "old ballot data" to separate drives and have new data "stream into" latest partitions only. For all the practical purposes, current queries access only a fraction of total table size most of the time.

This way you can still use reporting over the whole table (all ballots) without having to joggle between different databases.

---

If:

• the ballots once closed effectively become read-only, and
• are also self-contained and unrelated to other ballots,

Then yes, it would seem to make sense to separate them for performance reasons.

Are any tables shared across all ballots? (eg. app-wide configuration) That information would then need to sit in it's own DB.