Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Data replication between view and table within same database Expand / Collapse
Author
Message
Posted Saturday, September 22, 2012 2:07 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, September 28, 2012 10:32 PM
Points: 2, Visits: 2
Is it possible to do transaction replication of data from view into table in same database. I have final view based on multiple views but retrieving data from final view takes for ever due to size of data and processing complexity. Would like to replicate data from this final view into physical table for faster performance.

Replication: Won't let me select same database as Publisher and subscriber
TableDiff: Gives me message that it needs PK,GUID,Unique ley on view. Although I have column with NewId() on view, it is not getting detected as unique key by TableDiff.

Server is 2008R2.

--
Post #1363168
Posted Sunday, September 23, 2012 2:38 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 2:06 AM
Points: 1,768, Visits: 8,318
When you replicate a view, then it will look to replicate the base data (i believe).
In any case, sounds like an indexed view would be better for your circumstances, have you tried and ruled one out ?




Clear Sky SQL
My Blog
Kent user group
Post #1363205
Posted Sunday, September 23, 2012 10:01 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:12 AM
Points: 7,135, Visits: 12,746
You cannot replicate a regular view because in a regular view the data is not materialized. You can however replicate an indexed view for that same reason.

It sounds like one of your issues is that you are using nested views. Nesting views in SQL Server is an anti-pattern and it sounds like you have reached a level of complexity to where it is causing problems for the database engine. By attempting to materialize the data in the outer view you are only treating the symptom. I would suggest you do a design and performance review on all your views. You may be better off making some of the inner views referenced in your outer view into indexed views.

See Sin Indulging in Nested Views > The Seven Sins against TSQL Performance (31 July 2012) by Grant Fritchey

Detangling Nested Views (June 30, 2010) by Jen McCown


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1363240
Posted Friday, September 28, 2012 12:05 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, September 28, 2012 10:32 PM
Points: 2, Visits: 2
Yes you are correct, I am using nested views that cotains CTEs to process data from various source tables and views. So can't use materilized views. I believe Materilized view will have to be based on actual tables and cannor reference other views.

My problem is that I have few level of tables that involves huge amount of data processing, If I was to convert each of them into table, it would result in various updated that I will need to manage to refresh those tables. Some of them needs to happen when set of records are inserted in source table, so calling such process to refresh destination in trigger would be bad ideda as it would process thousands of records for every record inserted where as it is required only after set of records are inserted in source.

Updates has a ripple effect, that means when two or more source tables are updated they result in updates for two or more destination tables, which in turn would result in further level updates (need to reprocess data). I need to find out alternative way to achieve performance as well as to handle concurant updates to same tables in multi user scenario.

Rgds
Post #1365623
Posted Friday, September 28, 2012 10:49 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:12 AM
Points: 7,135, Visits: 12,746
The more work you can lift off those outermost views the better. That's what I mean by materializing the inner views. Views referencing views that reference base tables are bad enough. If your view hierarchy is deeper than even a simple two levels then you may need to rethink what's happening. I might suggest you move in the direction of converting some of these views to stored procedures or inline-table-valued functions and get out of the business of using views.


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Post #1366019
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse