Не удалось создать индекс в представлении привязки схемы

Question

Невозможно создать индекс для представления привязки схемы ниже. Он создается из другого представления (v_prod_manu_sub). Ниже показано сообщение об ошибке msg 'Невозможно создать индекс для представления "dbo.V_PROD_MANU", поскольку он ссылается на производную таблицу "X" (определяется оператором SELECT в предложении FROM).Попробуйте удалить ссылку на производную таблицу или не индексировать представление. Как изменить этот приведенный ниже запрос для создания индекса .?

ALTER VIEW [dbo].[V_PROD_MANU] WITH SCHEMABINDING AS
SELECT X.PRODUCT, CAST(RIGHT(TEXT_CODE,LEN(F_TEXT_CODE)-1) AS VARCHAR(30)) AS TEXT_CODE,
    CAST(SUBSTRING(RIGHT(PHRASE,LEN(F_PHRASES)-1),9,LEN(F_PHRASE)-3) AS varchar(700)) AS PHRASE
    FROM (
    SELECT V1.PRODUCT,
    (SELECT ',' + V2.TEXT_CODE FROM dbo.V_PROD_MANU_SUB V2 WHERE V1.PRODUCT = V2.PRODUCT ORDER BY V2.F_COUNTER  FOR XML PATH('')) AS TEXT_CODE,
    (SELECT ' |par|par ' + V3.F_PHRASE FROM dbo.V_PROD_MANU_SUB V3 WHERE V1.PRODUCT = V3.PRODUCT ORDER BY V3.F_COUNTER FOR XML PATH('')) AS PHRASE
FROM dbo.V_PROD_MANU_SUB  V1 GROUP BY V1.PRODUCT)X

OUTPUT

Product         TEXT_CODE                PHRASE 
00-021      MANU0043,MANU0050     Inc |par  Pharmaceuticals Group |par  235 East 5nd Street |par usa |par 1-800-123-000

Answer 1

Обычно люди используют STUFF(), чтобы удалить начальную запятую, вместо этих грязных преобразований и LEN() вычислений.Например:

SELECT V1.PRODUCT,
    TEXT_CODE = STUFF
    (
      (
        (SELECT ',' + V2.TEXT_CODE 
           FROM dbo.V_PROD_MANU_SUB AS V2 
           WHERE V1.PRODUCT = V2.PRODUCT 
           ORDER BY V2.F_COUNTER  
           FOR XML PATH, TYPE).value('.[1]','nvarchar(max)')
      ),
    1,1,N'')
FROM dbo.V_PROD_MANU_SUB AS V1 
GROUP BY V1.PRODUCT;

-- much easier in SQL Server 2017 with STRING_AGG()

Но это, похоже, не имеет никакого отношения к тому, зачем вам в первую очередь материализовывать разделенный запятыми список, независимо от того, содержит ли он запятую или нет.

Индексированные представления часто являются формой преждевременной оптимизации.По сути, вы говорите: «Стоимость запроса этих данных будет намного больше, чем стоимость их обслуживания».Вы это знаете?Как?Какой у вас баланс рабочей нагрузки (читай: пиши)?Насколько медленный сейчас запрос?Как часто это работает?Сколько времени занимают обновления?

Если вы это знаете, вам повезет, материализуя их на свой собственный стол, вручную, через триггер.Индексированное представление вполне может оказаться тупиком по разным причинам.