Qual é o benefício de ter varbinary campo em uma tabela separada 1-1?

Question

Eu preciso armazenar arquivos binários em um varbinary (max) de coluna no SQL Server 2005 como isto:

FileInfo

• FileInfoId int, PK, identidade
• FileText varchar (max) (pode ser nulo)
• FileCreatedDate datetime etc.

fileContent

• FileInfoId int, PK, FK
• fileContent varbinary (max)

FileInfo tem um 1-1 relação com fileContent. O FileText é feito para ser usado quando não há nenhum arquivo para upload, e só texto será inserido manualmente para um item. Eu não tenho certeza qual a porcentagem de itens terão um arquivo binário.

Devo criar a segunda tabela. Haveria quaisquer melhorias de desempenho com o design de dois mesa? Existem benefícios lógicos?

Eu encontrei desta página , mas não certeza se ela se aplica no meu caso.

Answer 1

Não há desempenho nem vantagem operacional. Desde SQL 2005 os tipos LOB são já armazenado para você pelo motor em uma unidade de alocação separada, um b-árvore separada. Se você estudar a Tabela e Organização Índice do SQL Server você vai ver que cada partição tem até 3 unidades de alocação: dados, LOB e estouro de linha:

Um campo LOB (varchar (max), nvarchar (max), varbinary (max), XML, UDTs CLR, bem como o texto tipos obsoleto, ntext e imagem) terá no próprio registo de dados, o índice agrupado , apenas uma pegada muito pequena: um ponteiro para a unidade de alocação LOB, consulte anatomia de um registro .

Ao armazenar uma LOB explicitamente em uma tabela separada você ganha absolutamente nada . Você acabou de adicionar complexidade desnecessária como ex-atualizações atômicas tem que distribuir-se agora em duas mesas separadas, complicando o aplicativo e a estrutura de transação de aplicação.

Se o conteúdo LOB é um arquivo inteiro, então talvez você deve considerar atualizar para SQL 2008 e usando FILESTREAM .

Answer 2

Não existe uma verdadeira lógica vantagem para este design de duas tabelas, uma vez que a relação é 1-1, você pode ter todas as informações agrupadas na tabela de FileInfo. No entanto, existem sérias operacional e desempenho vantagens, nomeadamente se os dados binários é mais do que algumas centenas de bytes de tamanho, em média.

EDIT : Como foi assinalado por Remo Rusanu, em algumas implementações, tais como DBMS SQL2005, os grandes tipos de objectos são armazenados de forma transparente para uma tabela separada, efectivamente aliviar a desvantagem prática de ter grandes registos. A introdução deste recurso confirma implicitamente o [verdadeiro] fraqueza da abordagem única tabela.

Eu apenas examinou a postagem SO referenciados nesta questão. Eu geralmente coisa que ao mesmo tempo que outra postagem faz alguns pontos válidos, tais como integridade de dados intrínseco (uma vez que todas as ações CRUD em um determinado item são atômicas), mas no geral, ea menos de casos de uso relativamente atípicos (como usar o item mesa como um repositório principalmente consultado para itens únicos de cada vez), a vantagem de desempenho é com as duas tabelas aproximar (em que índices na tabela "header" será mais eficiente, as consultas que não exigem os dados binários vai voltar muito mais rapidamente etc . etc.)

E a abordagem duas tabelas tem mais benefícios no caso dos evolui de design para fornecer diferentes tipos de objetos binários no contexto differnt. Por exemplo, digamos que esses itens são imagens (GIFs, JPGs etc.). Numa data posterior você também quiser fornecer uma versão pequena pré-visualização dessas imagens (e / ou uma versão oi-resolução), a escolha deste sendo impulsionado pelo contexto (de preferência do usuário, baixos clientes da banda de largura, assinante vs. visitante etc). Em tal caso, um não só são as questões operacionais associados com a abordagem única tabela feita mais aguda, o modelo se torna mais versátil.

Answer 3

Pode ajudar a imagem separada, (N) TEXT, (N) VARCHAR (max) e varbinary (max) colunas de tabelas mais largas puramente para algumas restrições de SQL Server.

Por exemplo antes de 2012, não foi possível on-line reconstruir uma tabela em cluster se contivesse LOBs. Por outro lado, você pode não se preocupam com essas restrições, de modo a configuração da tabela como seus dados está relacionada é a melhor coisa a fazer.

No caso de pretender fisicamente para manter os dados LOB para fora da unidade de alocação de mesa você ainda pode definir os "tipos de valores grandes fora de linha" opção de tabela .