Coming off the heels of significant change in 2005, replication is one of a few quiet areas in terms of version differences in SQL Server 2008. Indeed, virtually nothing has changed that isn't directly tied to a non-replication feature. (They had to allow for replication of the new data types, didn't they?)
Replication is one of those things that everyone loves to ignore — until they need it. Then, it seems, there is a sudden crisis about learning and implementing it instantly (and not necessarily in that order, I'm sorry to say).
So, what then, exactly, is replication? I'll shy entirely away from the Webster's definition of it and go to my own definition:
Replication is the process of taking one or more databases and systematically providing a rule-based copy mechanism for that data to and potentially from a different database.
Replication is often a topology and administration question. As such, many developers have a habit of ignoring it — bad idea. Replication has importance to software architects in a rather big way, as it can be a solution to many complex load and data distribution issues such as:
Making data available to clients that are generally not connected to your main network
Distributing the load associated with heavy reporting demands
Addressing latency issues with geographically dispersed database needs
Supporting geographic redundancy
And those are just a few of the biggies.
So, with that in mind, we're going to take a long look at replication. I'm ...