Pre-Comparison Filtering?
raymond.dazo
Posts: 4
Hi Red-Gate Team,
We have a very important task that we need only to compare a limited number of database objects against the source database. Red-Gate does compare every objects first before you could filter the objects to sync, thus the post-comparison filtering.
One of your support posted something about pre-comparison filtering:
http://www.red-gate.com/messageboard/vi ... ght=filter
I would like to ask what is Red-Gate's plan regarding this, would your team implement a pre-comparison filtering? If so, when would be the target date?
Regards,
Raymond Dazo
We have a very important task that we need only to compare a limited number of database objects against the source database. Red-Gate does compare every objects first before you could filter the objects to sync, thus the post-comparison filtering.
One of your support posted something about pre-comparison filtering:
http://www.red-gate.com/messageboard/vi ... ght=filter
I would like to ask what is Red-Gate's plan regarding this, would your team implement a pre-comparison filtering? If so, when would be the target date?
Regards,
Raymond Dazo
Comments
Thanks for the question.
Can I ask which database version you are developing on? For SQL Server 2000 and 2005 we need to read the entire databse to build a dependency tree. For SQL Server 2008, because we it holds accurate dependency information we could in theory provide pre-comparison filtering. There is no timeframe for when this might be, and it would depend on the extent of SQL Server 2008 adoption as well as customer demand.
Is post-comparison filtering not fast enough for you at the moment?
David Atkinson
Product Manager
Red Gate software
Product Manager
Redgate Software
There's a big performance difference when comparing the full size source database against a trim down target database (where our selected objects are stored).
For example:
We have a full size source database which 3gb in size. Then we have a trim down version (target DB) which is 441mb only. All objects (including the dependencies) in the latter database can be found in the source database.
Comparing the trim down db against the full size source doesn't eat that much time but it's the time registerting the full size source that eats a lot of time.
The larger the database is the longer it takes to register.
Oh, I guess I just realized what's the main issue that we have with your product. I think regardless if you were able to implement the pre-comparison filtering on whichever version of SQL Server, it's the time to register the full size database that kills.
David
Product Manager
Redgate Software
SimonC