4 ms·
Perhaps I can add some context on top of the post. All updates are in transactions unless explicitly opted out. Also remember our case is a little special: we h
by Nick-Craver 10y ago
Perhaps I can add some context on top of the post. All updates are in transactions unless explicitly opted out. Also remember our case is a little special: we have hundreds of the databases with the same schema, what if #328 fails? The failure/rollback scenario is a bit more complicated when you go past a single database involved.
As for backups: absolutely. We handle this independently though. We do full backups every night as well as T-logs every 15 minutes. If I had to restore every database we had to a very specific point in time or just before a migration command was run: we have T-logs to do that going back 4 days at all times.
I'm sure there are good solutions for single database applications way more fully featured than our approach, they just do little to solve any problems we actually run into.
- ufo 10y agoWhy hundreds of databases? One for each stackexchange site?
- aalear 10y agoTwo per site - one for main Q&A, one for its meta.
- nickpsecurity 10y agoYou couldn't do one with some different tables? What was justification for both separate DB's and the Q&D/meta split? Just curious.
- Nick-Craver 10y agoIf you did different tables, that's even more complicated by making every query dynamic. It also makes backups, etc. far more complicated as well. Multiple databases is simply the simplest solution for multiple things that need a database with the same schema :)
- nickpsecurity 10y agoAppreciate the tip.