Updateable view in mssql with multiple tables and computed values

Question

Huge database in mssql2005 with big codebase depending on the structure of this database.

I have about 10 similar tables they all contain either the file name or the full path to the file. The full path is always dependent on the item id so it doesn't make sense to store it in the database. Getting useful data out of these tables goes a little like this:

SELECT a.item_id
, a.filename
FROM (
    SELECT id_item AS item_id
    , path AS filename
    FROM xMedia

    UNION ALL

    -- media_path has a different collation
    SELECT item_id AS item_id
    , (media_path COLLATE SQL_Latin1_General_CP1_CI_AS) AS filename
    FROM yMedia

    UNION ALL

    -- fullPath contains more than just the filename
    SELECT itemId AS item_id
    , RIGHT(fullPath, CHARINDEX('/', REVERSE(fullPath))-1) AS filename
    FROM zMedia

    -- real database has over 10 of these tables
) a

I'd like to create a single view of all these tables so that new code using this data-disaster doesn't need to know about all the different media tables. I'd also like use this view for insert and update statements. Obviously old code would still rely on the tables to be up to date.

After reading the msdn page about creating views in mssql2005 I don't think a view with SCHEMABINDING would be enough.

How would I create such an updateable view?

Is this the right way to go?

Answer 1

Scroll down on the page you linked and you'll see a paragraph about updatable views. You can not update a view based on unions, amongst other limitations. The logic behind this is probably simple, how should Sql Server decide on what source table/view should receive the update/insert?

Answer 2

You can modify partitioned views, provided they satisfy certain conditions.

These conditions include having a partitioning column as a part of the primary key on each table, and having a set on non-overlapping check constraints for the partitioning column.

This seems to be not your case.

In your case, you may do either of the following:

• Recreate you tables as views (with computed columns) for your legacy soft to work, and refer to the whole table from the new soft
• Use INSTEAD OF triggers to update the tables.