Um tipo de dados afeta o desempenho em uma exibição?

Para responder à pergunta geral primeiro, sim, o tipo de dados nas visualizações pode afetar o desempenho. Vamos simular alguns dados para ilustrar um exemplo trivial:

DROP TABLE IF EXISTS X_162798;

CREATE TABLE X_162798 (
NUM_VARCHAR VARCHAR(10), 
NUM_INT INT,
[Status] INT,
IncludeInJobTotals as (CONVERT(bit, 
case 
when [Status]=(5) 
  or [Status]=(3)
  or [Status]=(2) 
then (1) 
else (0) 
end,(0)))
);

-- insert 1 M rows with 999990 of them having a value of 1 for IncludeInJobTotals
WITH
  L0   AS(SELECT 1 AS c UNION ALL SELECT 1),
  L1   AS(SELECT 1 AS c FROM L0 AS A CROSS JOIN L0 AS B),
  L2   AS(SELECT 1 AS c FROM L1 AS A CROSS JOIN L1 AS B),
  L3   AS(SELECT 1 AS c FROM L2 AS A CROSS JOIN L2 AS B),
  L4   AS(SELECT 1 AS c FROM L3 AS A CROSS JOIN L3 AS B),
  L5   AS(SELECT 1 AS c FROM L4 AS A CROSS JOIN L4 AS B),
  Nums AS(SELECT ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS n FROM L5)
INSERT INTO X_162798 WITH (TABLOCK)
SELECT 
CAST(n AS VARCHAR(10))
, n
, CASE WHEN n <= 10 THEN 0 ELSE 5 END
FROM Nums 
WHERE n <= 1000000;

UPDATE STATISTICS X_162798 WITH FULLSCAN;

-- index all the columns
CREATE INDEX IX_162798_NUM_VARCHAR ON X_162798 (NUM_VARCHAR);
CREATE INDEX IX_162798_NUM_INT ON X_162798 (NUM_INT);
CREATE INDEX IX_162798_STATUS ON X_162798 ([Status]);
CREATE INDEX IX_162798_JOB ON X_162798 (IncludeInJobTotals);

DROP VIEW IF EXISTS V_162798;

GO

CREATE VIEW V_162798
AS
SELECT
CAST(NUM_VARCHAR AS INT) NUM_INT_CASTED
, NUM_VARCHAR 
, IncludeInJobTotals
, CONVERT(INT, IncludeInJobTotals) IncludeInJobTotals_INT
FROM X_162798;

GO

As duas consultas a seguir retornam os mesmos resultados, mas o desempenho é muito diferente:

-- this query does a table scan and does an estimate based on density
SELECT *
FROM V_162798
WHERE NUM_INT_CASTED = '1';

-- this query does an index seek and does an estimate based on the histogram 
SELECT *
FROM V_162798
WHERE NUM_VARCHAR = '1';

Se eu fizer o tipo errado de conversão de tipo de dados, o filtro não será mais sargável . Ele não pode usar um índice na coluna e a oferta de estimativas de cardinalidade sofre porque o histograma não pode ser usado.

Importa no seu caso onde você lança uma BITcoluna para um INTEGER? Podemos filtrar nas colunas IncludeInJobTotalse IncludeInJobTotals_INTna exibição para executar alguns testes. Com base na precedência do tipo de dados , devemos esperar que a BITseja convertido em an INTEGERem qualquer comparação entre a BITe an INTEGER. O SQL Server deve ser capaz de fazer uma conversão implícita entre eles , então acho que será difícil encontrar um problema de desempenho.

Como estamos lidando com uma coluna de bits, não há muitos casos de teste possíveis para filtros simples. Se eu filtrar em qualquer coluna da exibição procurando por linhas com um 0valor, sempre recebo buscas de índice e uma estimativa de cardinalidade correta:

-- all queries do an index seek and estimate 10 rows will be returned
SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals = 0;

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals_INT = 0;

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals = CAST(0 AS BIT);

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals_INT = CAST(0 AS BIT);

Se eu filtrar em qualquer coluna da exibição procurando por linhas com um 1valor, sempre recebo uma verificação de tabela e uma estimativa de cardinalidade correta:

-- all queries do a table scan and estimate 999990 rows will be returned
SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals = 1;

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals_INT = 1;

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals = CAST(1 AS BIT);

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals_INT = CAST(1 AS BIT);

A procura de valores fora do intervalo também funciona como esperado:

-- these queries do an index seek and estimate 1 row will be returned
SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals = 2;

SELECT NUM_VARCHAR
FROM V_162798
WHERE IncludeInJobTotals_INT = 2;

Eu não me preocuparia com o desempenho para esse tipo de alteração de tipo de dados. É difícil imaginar um cenário no qual você teria problemas de desempenho. No entanto, é importante observar que as consultas que usam a exibição podem retornar resultados diferentes dependendo de como você usa a coluna. O tipo de dados BIT se comporta de maneira diferente de INT:

A conversão para bit promove qualquer valor diferente de zero para 1.

Voltando à lista de precedência de tipo de dados, um VARCHARvalor será convertido em um BITvalor. Isso significa que uma maneira de obter resultados diferentes é filtrar ou unir um VARCHARvalor fora do intervalo:

CREATE TABLE TABLE_WITH_THE_NUMBER_2 (NUM VARCHAR(1));
INSERT INTO TABLE_WITH_THE_NUMBER_2 VALUES ('2');

-- this query returns 999990
SELECT COUNT(*)
FROM V_162798 v
INNER JOIN TABLE_WITH_THE_NUMBER_2 t ON v.IncludeInJobTotals = t.NUM;

-- this query returns 0
SELECT COUNT(*)
FROM V_162798 v
INNER JOIN TABLE_WITH_THE_NUMBER_2 t ON v.IncludeInJobTotals_INT = t.NUM;

Talvez seu aplicativo nunca faça isso, mas o que você quer que aconteça nesse cenário? Eu me concentraria na correção aqui sobre o desempenho.