February 11, 2013 at 10:15 pm
Hello Folks,
we are planning to replicate database for reporting purpose and we need to restrict data based on companyID'
we are not supposed to replicate any data that is greater than companyID five.(campanyid >5)
we have total of 50 tables and out of which companyID exists on 30 tables and I can easily apply row filter to filter the data by companyID >5 on these tables but the other 20 tables doesnt have companyid but those tables have information of all companies.
What is the best way to replicate other 20 tables data without sending restrcited data? I do have a way to get data of companies <5 but I need to apply multiple joins depending on tables.
As I cant apply joins with other tables at row filter level ,what are my possible options?
I thought of following but not sure if they are possible
1) alter the default I/D/U procedures by joining them with other tables to only replicate required data.
I am not sure if above option works but wondering how I can generate intial snaphot with this solution.
2)
Planning to create functions and use at row filter level but not sure if I can use functions at row filter level in replication. Yet to test this solution
3) replciate all data to reporting system and create views in top of tables to restrict data.
I dont think its a ideal solution but I just thought of it..
Please advice if you think of any better solution...
any advice is really appreicated...
April 30, 2013 at 11:29 am
I am not sure you can accurately partition your articles without that company identity column. Are the company names consistent across the tables that you can join to the company table on the name field? if so , add a company id column to those other tables. Always beware of views that depend on those tables that do a 'select *' (not a recommended practice). Otherwise, views and stored procedures are acceptable article elements.
----------------------------------------------------
May 1, 2013 at 12:52 pm
You can create indexed view on the Publisher based on your filter criteria and publish that view.
May 1, 2013 at 1:07 pm
From MSDN,
http://msdn.microsoft.com/en-us/library/ms187864%28v=sql.105%29.aspx
Indexed views work best when the underlying data is infrequently updated. The maintenance of an indexed view can be greater than the cost of maintaining a table index.
Plus also keep in mind
an indexed view cannot reference tables from more than one database.
----------------------------------------------------
May 1, 2013 at 1:09 pm
Yep. I did went with indexed views and going well so far.
Thanks for responding even on older thread. I appreciate it.
May 1, 2013 at 3:55 pm
Glad its working out, thanks.
----------------------------------------------------
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply