Isenção de responsabilidade
Eu tive uma ideia para um design de mesa há pouco tempo que fez sentido para mim na época. Na história recente, percebi que tenho o hábito de "engenharia em excesso" ou gastar muito tempo tentando "otimizar demais" as soluções. Estou assumindo que este é um daqueles casos em que estou pensando demais na solução e criarei uma sobrecarga extra com pouco ou nenhum ganho real.
Pergunta
Suponha que para um objeto (um Shipment tablepor exemplo) existe algum tipo de NOTE varchar(MAX)elemento de dados que queremos acompanhar. O NOTE columntem a oportunidade de ter dados empurrados para um estouro e aumentar drasticamente o tamanho do row(limitando assim o número rowsque pode ser salvo no page). Pelo que entendi, isso impacta negativamente no tempo de execução de várias operações na tabela como um todo.
Existe algum caso em que devemos empurrar isso columnpara um stand separado sozinho ShipmentNote tableem vez de mantê-lo como columnum Shipment table? A teoria é que, se empurrarmos o NOTE columnpara um separado table, ele salva o pageson the, o Shipment tableque permite que todas as operações no the Shipment tabletenham um desempenho melhor. Porque o rowtamanho é menor e agora você pode caber mais rowsno mesmo page.
(Veja exemplos de esquema abaixo):
O principal caso de uso em que isso pode ser uma boa ideia é se:
- O
Notecolumné regularmente mais de 8000 caracteres (o que eu acho que é quando começamos a usar a paginação extra) - O
Notecolumnúnico retornado emSELECToperações e raramente ou nunca é usado como parte de umJOINouWHERE - O restante será consultado independentemente de
columnsforma regular (IE: a maioria de nossas operações, não utilizará , seja isso ou condições acontecendo em outros em `Remessa)ShipmentNoteNoteJOINWHEREcolumns
As desvantagens que estou vendo (fora disso, podem não fazer melhorias perceptíveis no trabalho com a Shipmenttabela fora da Notecoluna):
- Agora se torna impossível (ou pelo menos requer um
triggerou outra coisa) garantir que sempre haja algum tipo de valor paraNOTE(IE: porque agora está em um separadochild table, não podemos garantir queNOTEsejaNOT NULLpara todosrowemShipment - Qualquer operação utilizando
NOTEagora exigirá um esforço extra, devido à necessidade de fazer umJOINpara garantir que estamos trabalhando com o registro correto
Embora seja ótimo que você esteja pensando nisso - eu consideraria isso uma micro-otimização. O SQL Server já possui otimizações incorporadas para manipulação
NVARCHAR(MAX)e, geralmente, eu diria para não adivinhar até que se torne um problema. No entanto, há dois pontos principais que vieram à mente ao ler sua pergunta.A primeira é (como você mencionou no último ponto) haveria realmente algum desempenho obtido ao dividir os dados em outra tabela, deixando o SQL Server otimizar as páginas e os dados em si? Não tenho provas concretas comigo agora, mas suspeito que não. A razão é que, como você mencionou, seus dados estão regularmente acima de 8.000 bytes e, portanto, serão movidos para páginas LOB em sua tabela de notas de qualquer maneira. Você estaria apenas movendo o problema percebido de uma mesa para outra. Adicione a sobrecarga de executar um
JOINquando tiver que buscar os dados e você provavelmente acabará um pouco pior do que estava no início.Em segundo lugar, como você marcou a pergunta com design de banco de dados, minha recomendação real é que você divida as notas em outra tabela. No entanto, meu raciocínio não é tanto impulsionado pela otimização de desempenho, mas mais especificamente adicionando flexibilidade ao aplicativo. É muito provável que uma remessa precise de mais de uma nota anexada a ela (por exemplo, se estiver atrasada em trânsito, ou um cliente ligar etc...). Se você tiver a nota na própria remessa, fica mais difícil fazer isso sem duplicar os dados. Se você extraí-lo em sua própria tabela, poderá atribuir várias notas a uma remessa e rastrear quem as inseriu e quando. Isso torna seu aplicativo e banco de dados mais flexíveis.
Se você deseja otimizar, recomendo remover a necessidade de consultar as notas, a menos que alguém queira visualizá-las especificamente (como ter um formulário dedicado em seu aplicativo para fazer isso). Dessa forma, você só precisa realizar a junção/pesquisa quando alguém explicitamente deseja visualizar os dados. Mesmo que você não tenha externalizado as notas para outra tabela, não incluir a coluna na consulta se não for necessária removerá a necessidade de o SQL Server ler a página LOB. Se possível, sempre otimizaria as consultas para retornar a menor quantidade de informações necessárias antes de otimizar em um nível micro.
A resposta simples é não, a menos que você tenha um aplicativo que sempre busque todas as colunas da tabela e precise evitar que ele recupere as notas toda vez que consultar uma Remessa.
Se você decidir, pode instruir o SQL Server a nunca armazenar as notas na linha e usar um ponteiro para um LOB separado com a opção de tabela 'tipos de valor grande fora da linha' e pode até enviar esses LOBs para um grupo de arquivos separado por definindo a opção TEXTIMAGE_ON em CREATE TABLE .