0

I want to build a clustered and/or replicated relational database so that all of the company's apps can use the same data without manually shuffling it between databases.

However, this raises two issues:

  • A bad update or delete query can disable all apps and services
  • If all storage is unified, how do we handle staging?

My thoughts on this is that something like transaction-based version control for data (like git for source) could be useful, but in general I could use any idea on how to mitigate these issues.

Improve this question

1 Answer 1

Reset to default
3

A bad update or delete query can disable all apps and services

  • With great power comes great responsibility. Fine-grain the database user permissions and make sure that only the users that understand that have the power.
  • Use sandbox systems, do not do development on production.
  • Have a way to rollback changes / restore database at hand. Test it.

If all storage is unified, how do we handle staging?

Like you say, use versioning. Application code versioning [e.g. svn] and you might also try database versioning [ and e.g. Jenkins for deployment].

Improve this answer
3
  • What if the worst happened? Can I configure a database to allow for (maybe limited) undoing of transactions?
    – Aleksei Averchenko
    Jun 5, 2015 at 16:13
  • 1
    yes, it is possible, depending on your database flavour, look for transaction rollback. In Oracle for example, you alter database archivelog and all the redo logs [files that hold the changes to the database] will be archived instead of being overwritten allowing you to go for point in time recovery for example.
    – 7y7
    Jun 5, 2015 at 19:35
  • Is there a database engine that specifically features such a system? I'm especially interested in forking and merging database versions
    – Aleksei Averchenko
    Jun 5, 2015 at 21:55

Not the answer you're looking for? Browse other questions tagged .