John's questions

Posso definir uma restrição (lógica) PRIMARY KEY, servida por um NONCLUSTERED INDEX (físico), para que verifique apenas determinados valores da coluna restrita e indexada ou outra coluna na tabela relevante?

E, em caso afirmativo, essa coluna pode ser estabelecida como uma restrição FOREIGN KEY referenciada em outras tabelas?

Estou tentando basicamente ver se posso remover certas linhas de uma tabela pai sem remover essas linhas de uma tabela filha , mas ainda impor o relacionamento para, por exemplo:

• IDs > 1000, ou
• CreatedDateTime > RemovalDate.

Por exemplo, você pode ter esse tipo de restrição:

ALTER TABLE MyTable WITH NOCHECK ADD 
    CONSTRAINT PK_MyTable CHECK (Id > 1000)

mas como você definiria esta coluna como uma PRIMARY KEY fixa com um NONCLUSTERED INDEX?

E posso fazer algo como a seguinte definição:

ALTER TABLE MyTable WITH NOCHECK ADD 
    CONSTRAINT PK_MyTable CHECK (CreatedOn > '01/01/2010')

mas tem um INDEX para a coluna chamada Id?

Existe um método ou sintaxe que permita que uma tabela que tenha apenas uma coluna rowversion/timestamp seja preenchida com dados?

CREATE TABLE [dbo].[TimeStamp_Test]([row_version] [timestamp] NOT NULL)

Temos algumas tabelas de produção com inúmeras restrições que não são confiáveis ​​no momento. Estamos verificando/confiando para que possam ser usados ​​novamente. Sabemos que o otimizador não os tem usado em seus planos (porque não eram confiáveis). Tenho duas perguntas antes de defini-las novamente como confiáveis.

1. O otimizador reconhecerá a alteração e as considerará antes de usar planos de consulta em cache para transações reexecutadas? Dito de outra forma, preciso considerar a remoção de quaisquer planos de consulta?

2. É seguro dizer que esta é uma situação em que o SQL Server está reconstruindo o índice (estamos ativados) e mantendo o índice durante inserções, atualizações e exclusões, mas simplesmente não usando a chave estrangeira?

Obrigado

Eu tenho uma tabela com uma restrição que possui um registro existente que viola essa restrição. Embora isso seja possível se alguém aplicasse a restrição sem uma verificação e depois que os dados de violação fossem inseridos, como seria possível que o sinalizador is_not_trusted fosse zero na tabela sys.foreign_keys?

Esta é a situação que tenho atualmente, uma violação de dados em uma chave estrangeira onde o sinalizador is_not_trusted é zero. Eu pensei que era essencialmente o sinalizador que confirma se a restrição foi aplicada 'religiosamente'.

Obrigado