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?

Was it helpful?

Solution

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.

OTHER TIPS

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?

If a view is based on multiple base tables, UPDATE statement on the view may or may not work depending on the UPDATE statement. If the UPDATE statement affects multiple base tables, SQL server throws an error. Whereas, if the UPDATE affects only one base table in the view then the UPDATE will work (Not correctly always). The insert and delete statements will always fail.

INSTEAD OF Triggers, are used to correctly UPDATE, INSERT and DELETE from a view that is based on multiple base tables. The following links has examples along with a video tutorial on the same.

INSTEAD OF INSERT Trigger
INSTEAD OF UPDATE Trigger
INSTEAD OF DELETE Trigger

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top