I think it would make a great deal of sense to split the configuration database and the data database.
Fortunately such a step would not affect existing installations - you simply configure both to be in the same place.
essentially the two types of information are different in all all respects - usage pattern, value, volume. by allowing them to reside in two different databases, you increase the DBAs flexibility to handle them in appropriate ways - raid 1 + replication + backups for the config; raid 0 for the data.
cons:
Additonal complexity to handle two databases
Additional complexity handling the case where the configuration database is up, but the data one is down.
Fortunately such a step would not affect existing installations - you simply configure both to be in the same place.
essentially the two types of information are different in all all respects - usage pattern, value, volume. by allowing them to reside in two different databases, you increase the DBAs flexibility to handle them in appropriate ways - raid 1 + replication + backups for the config; raid 0 for the data.
cons:
Additonal complexity to handle two databases
Additional complexity handling the case where the configuration database is up, but the data one is down.
Comment