sovguy's questions

A situação é que tenho uma tabela de inquilino e uma tabela de pesquisa de status baseada em inquilino. Cada um com suas próprias chaves primárias de numeração automática.

Agora quero adicionar uma coluna à tabela Tenant para um Status padrão que faça referência à tabela de pesquisa, o inquilino só deve poder padronizar para um status que esteja nesse inquilino e, por algum motivo, a estrutura exata do FK está bagunçada com a cabeça, então pensei em perguntar caso estivesse enlouquecendo haha.

ex Tabelas:

Inquilino:

Status:

Então, eu ia adicionar a chave estrangeira CONSTRAINT [FK_Tenant_Status] FOREIGN KEY ([defaultStatusID]) REFERENCES [dbo].[Status] ([statusID]), mas percebi que adoraria alguma maneira de garantir que o defaultStatusID seja de um status no locatário correto e não tenho certeza de qual é o melhor método para isso.

Adicionar inquilinoID ao FK parece errado porque inquilinoID não é estrangeiro para essa tabela e se tornaria circular? A menos que seja realmente tão fácil?CONSTRAINT [FK_Tenant_Status] FOREIGN KEY ([tenantID], [defaultStatusID]) REFERENCES [dbo].[Status] ([tenantID],[statusID])

Imagino que talvez algum tipo de restrição seja o caminho a seguir, mas não tenho certeza.

Obrigado por qualquer ajuda/comentários!

Eu tenho uma tabela SQL bastante simples (atualmente Azure SQL, pode ficar lá ou acabar na instância local do SQL Server 19, se isso for importante), cerca de 100.000 registros, que são principalmente para leitura, mas serão gravados gradualmente.

CREATE TABLE [dbo].[xCatalog](
    [catalogID] [int] IDENTITY(1,1) NOT NULL,
    [title] [nvarchar](255) NOT NULL,
    [dateA] [datetime] NULL,
    [dateB] [datetime] NULL,
    [textA] [nvarchar](25) NULL,
    [textB] [nvarchar](255) NULL,
    [textC] [nvarchar](255) NULL,
 CONSTRAINT [PK_xCatalog] PRIMARY KEY CLUSTERED 
(
    [catalogID] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO 

Digno de nota é o campo [title] nvarchar(255) , que será o que os usuários pesquisarão principalmente usando uma consulta formatada como abaixo usando "oceano" como termo de pesquisa de exemplo [title]

SELECT TOP(500) [catalogID],[title],[dateA],[dateB],[textA],[textB],[textC] 
FROM [dbo].[xCatalog] 
WHERE ([title] LIKE '%ocean%') 
ORDER BY [catalogID] ASC

Ele funciona razoavelmente bem, de 1 a 3 segundos, mas estou realmente interessado em mergulhar em como/se melhorá-lo, pois, francamente, tenho mais do que apenas uma compreensão superficial de coisas como índices e outras otimizações.

A consulta está sendo gerada por um programa front-end que não acredito que possa alterar, por isso está selecionando uma quantidade limitada classificada pela chave para retornar à rolagem virtual e por que não estou explorando a substituição de LIKE por Contém ou qualquer coisa assim.

Então, estou realmente tentando chegar a isso do lado do banco de dados e apenas entender quais seriam as melhores práticas e quais são as opiniões das pessoas sobre esse tipo de caso, no que diz respeito a que tipo de índice usar ou se mudar para ColumnStore seria aplicável (provavelmente muito pequeno?), etc. Também estamos usando um banco de dados SQL do Azure de nível básico, então talvez para esse tipo de operação nos beneficiássemos de aumentar um pouco isso.

Qualquer coisa assim para que eu possa saber daqui para frente e poder explicar com segurança que fiz x ou y para ajudá-lo, mas também talvez a pesquisa de caracteres curinga em texto grande às vezes seja cara, então quais deveriam ser minhas expectativas.

Apresentarei o plano de execução simples, caso seja útil:

Obrigado a todos pela contribuição! Eu sei que há muitas perguntas semelhantes que continuarei pesquisando, mas às vezes parece que são um pouco diferentes e imagino qual é o mal em perguntar também.