Data replication between view and table within same database

  • 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.

    --

  • 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[/url]

  • 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[/url]

    Detangling Nested Views (June 30, 2010) by Jen McCown[/url]

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • 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

  • 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

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply