This is a discussion on DB Replication or Table Replication via triggers? within the SQL Server forums, part of the Microsoft SQL Server category; --> Anthony Paul wrote: > I would *love* to have a full replication going and not have to worry > ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Anthony Paul wrote: > I would *love* to have a full replication going and not have to worry > about the added complexity of creating dynamic filters or triggers, > but the powers that be simply do not consider it an option. Since I'm > not the one that makes the decisions, I can only go by whatever > options are available. They want ONLY a subset of data to be captured, > nothing more. That would be fine with me if the filter was static (ie. > not subject to change every time a new report is requested) but given > the requirements I am in the same camp as you that a full replication > would be best. TPTB may start considering it an option if you give them a cost analysis, depending on whether their previous motivation was "wouldn't it be nice if" (yes, but) or "we think this is cheaper" (no it isn't) or "this is required for security reasons" (ugh, okay) or whatever. |
| ||||
| Anthony Paul (anthonypaulo@gmail.com) writes: > I would *love* to have a full replication going and not have to worry > about the added complexity of creating dynamic filters or triggers, > but the powers that be simply do not consider it an option. Since I'm > not the one that makes the decisions, I can only go by whatever > options are available. They want ONLY a subset of data to be captured, > nothing more. That would be fine with me if the filter was static (ie. > not subject to change every time a new report is requested) but given > the requirements I am in the same camp as you that a full replication > would be best. From my meager experience of replication, it seems clear that the database has to be really huge - several terabytes - to make a dynamic filtering defensible from a cost perspective. It would be difficult to develop, difficult to maintain and manage. The only serious option I see to full replication is a static subset. That is define what will be supported in replication V1. If a new reqiure- ment that is not covered, it would have to wait to V2. The idea would of course to only strip really big stuff with low proability to be included. And this is what you should tell the powers that be: replicating the entire database will be far less expensive than changing what is replicated dynamically. -- Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/pro...ads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinf...ons/books.mspx |