Would it be wrong to design a database, then duplicate that entire schema onto another server so that effectively there are two identical databases, operating in a master slave fashion, with the slave being updated overnight.

The idea of all this duplication is to improve speed since the master will be dealing with all the simple db tasks whilst the slave will be serving more processor intensive database mining queries.

This just seems wrong to me, I always though that good database design reduced duplication, but I need some solid arguments to return to my colleagues.

This is the principle behind replication... Create one logical database that can have many physical representations.

We have a setup exactly like that. We have one "interactive" or "publishing" database. One "subscriber" is used for reporting, big data trawls that have enormous locks and runtimes that we could never support in the database that is accepting new data. Another "subscriber" is used to interface between this system and our other systems (although any new data is still added through the "publisher" of the database. Each of the subscribers is a copy of the publisher, although the subscribers may well have additional tables added to serve their specific purpose.

While this is physical duplication, they are just copies of the publisher... That is no more troubling to my mind than a backup (which is just another kind of copy) of the publisher is!

-PatP

I think you've got two different concepts mixed up. Good design is about reducing duplication WITHIN a database. That is done for a variety of reasons. However, none of those reasons apply to what you are describing, which is a matter of duplicating the entire dataset for lookup purposes. Of course, that assumes that the"slaves" DO NOT accept any data, but are just there for the purposes of backup and / or intensive data mining, lookups, etc.