Jason's questions

Como parte de nossa manutenção noturna, incluímos a tarefa Check Database Integrity, que é um encapsulamento do comando DBCC CHECKDB. Está começando a levar um tempo considerável devido ao tamanho do nosso banco de dados e, depois de ler sobre o comando no MSDN , decidimos seguir o conselho deles:

Portanto, usar a opção PHYSICAL_ONLY pode causar um tempo de execução muito menor para DBCC CHECKDB em grandes bancos de dados e é recomendado para uso frequente em sistemas de produção. Ainda recomendamos que uma execução completa do DBCC CHECKDB seja executada periodicamente. A frequência dessas execuções depende de fatores específicos para negócios individuais e ambientes de produção.

Portanto, queremos alterar nosso plano para executar DBCC CHECKDB com a opção PHYSICAL_ONLY todas as noites e sem ela uma vez por semana. Existe alguma maneira de fazer com que o SQL Server inclua a opção PHYSICAL_ONLY na tarefa de integridade? Posso modificar de alguma forma o T-SQL produzido pela tarefa? Não consigo descobrir como incluir a opção como parte do plano de manutenção.

Portanto, meu chefe e eu estamos em desacordo sobre a melhor forma de projetar nosso banco de dados para armazenar dados diversos de determinados clientes.

Basicamente, temos um monte de tabelas em algum formato semelhante a este (em pseudo-código para simplificar):

TABLE [dbo].[SalesData]
[CampaignID] int IDENTITY(1, 1) NOT NULL, (This is the PK)
[CustomerID] int NULL,
[Calls] float NULL,
[Responses] float NULL,
[Sales] float NULL,
[Revenue] money NULL,
[Cost] money NULL,
[WebSales] float NULL,
[Channel] nvarchar(20) NULL

O que acontece é que, à medida que ganhamos clientes, às vezes somos forçados a adicionar algum tipo de coleta de dados personalizada para cada um. Para esta tabela, tudo é usado por cada cliente (temos cerca de 20), exceto WebSales e Channel, que é usado apenas por 1 cliente. Outro cliente deseja que alguns novos dados sejam rastreados e, portanto, precisamos adicionar mais colunas ou separar esses dados em uma tabela relacionada e iniciar um sistema de supertipo-subtipo.

O que eu quero fazer também é separar WebSales e Channel e adicionar uma tabela para cada cliente desta maneira:

TABLE [dbo].[SalesData_Client1] 
[CampaignID] int NOT NULL, (PK and FK to the SalesData table)
[WebSales] float NOT NULL DEFAULT 0,
[Channel] nvarchar(20) NOT NULL DEFAULT ''
ADD CONSTRAINT [CK__SalesData_Client1__CustomersCampaignID] 
CHECK (dbo.CustomerOfCampaignID(CampaignID) = Client1) 

Em seguida, descartaria essas colunas da tabela original e transformaria o segundo cliente em uma tabela como esta também. O chefe acha que isso significa que teremos que adicionar muitas tabelas à medida que ganhamos clientes e quer adicionar mais colunas. Ele prefere alterar a tabela SalesData assim:

TABLE [dbo].[SalesData]
[CampaignID] int IDENTITY(1, 1) NOT NULL, (This is the PK)
[CustomerID] int NULL,
[Calls] float NULL,
[Responses] float NULL,
[Sales] float NULL,
[Revenue] money NULL,
[Cost] money NULL,
[Unknown] char(10) NULL,
[Misc1] float NULL,
[Misc2] nvarchar(20) NULL
[Misc3] int NULL,
[Misc4] int NULL
[Misc5] int NULL

Onde as colunas "Misc" podem ser usadas para qualquer coisa, e então os programadores podem "simplesmente descobrir com base no cliente". Eu sei as razões pelas quais você não deveria fazer dessa maneira, isso viola a normalização e tornará o desempenho cada vez pior à medida que adicionamos colunas, etc. Mas ele continua voltando com "É muito mais simples" e não gosta disso cada novo cliente pode significar outra nova mesa. Ele também ressalta que colunas mais recentes, como Websales, podem ser usadas por mais de 1 cliente eventualmente, e será uma grande dor de cabeça tê-las em várias tabelas de subtipos ou movê-las de várias tabelas de subtipos para a tabela principal, se precisarmos sempre quis fazer isso.

Existe um método melhor do que a solução de supertipo/subtipo que eu criei para facilitar as coisas para ele e para os programadores? Uma observação importante é que os dados de cada cliente estão basicamente em seu próprio universo e NUNCA se misturarão. Sei que é meio subjetivo e a resposta dependerá de quantas colunas "Misc" estamos esperando seriamente. A razão pela qual quero seguir a rota do subtipo é porque o próximo cliente pode exigir 5 novas colunas bigint, pelo que sei.