Quando usar o tipo de dados XML

12

Sou responsável por criar um banco de dados em um projeto. Temos campos que raramente terão um valor (1 em cada 10.000 registros) e estou tentando descobrir a melhor maneira de armazenar isso no banco de dados.

Tanto quanto posso ver, tenho 3 opções:

  1. Adicione uma coluna na tabela para cada valor extra
  2. Adicione uma tabela vinculada que faça referência à tabela original e tenha registros apenas onde precisamos armazenar um valor
  3. Use o tipo de dados XML na tabela original e armazene todos os valores nela.

Existem outras opções que eu não considerei?

Estou tentando descobrir os prós e contras de cada método. Tanto quanto eu sei, 1 seria o mais fácil e 2 ocupariam menos espaço, mas estou lutando para encontrar muitos recursos para 3.

sql-server-2008 xml Matthew Steeples
fonte
1
Para adicionar um discurso pessoal contra o abuso de xml em um banco de dados, eu responderia diretamente à pergunta no título e diria um grande gordo: NUNCA! Para o corpo real da pergunta, deixarei os colegas ajudá-lo, porque você já tem respostas muito boas :-). PS: você pode realmente ignorar minha primeira frase.
Marian
De quantos campos extras você está falando? E eles fazem sentido fazer parte da mesma entidade?
Andrew Bickerton 31/03

Respostas:

12

Parece que você precisa de colunas esparsas e índices filtrados e segue a opção 1. Esses são recursos totalmente suportados e documentados exatamente para esse cenário.

O Mecanismo de Banco de Dados do SQL Server usa a palavra-chave SPARSE em uma definição de coluna para otimizar o armazenamento de valores nessa coluna. Portanto, quando o valor da coluna é NULL para qualquer linha da tabela, o valor não requer armazenamento.

Não consigo imaginar uma solução XML com bom desempenho nesse cenário, ela terá uma enorme sobrecarga de metadados redundantes e demora na consulta.

Gaius
fonte
1
Eu acho que colunas esparsas são o que eu estou procurando. Estou esperando que uma quantidade muito pequena de dados seja armazenada em provavelmente um punhado de colunas em determinadas tabelas.
Matthew Steeples
Não tenho certeza se estou lendo isso direito, mas, de acordo com este link, colunas esparsas são basicamente uma implementação de banco de dados do que eu estava procurando por 3, afinal? blog.sqlauthority.com/2008/07/14/…
Matthew Steeples
Se for implementado internamente dessa maneira (e eu não sei o que é, é apenas o blog de alguém), você nunca precisará lidar ou analisar o XML por conta própria - ele se comportará exatamente como uma tabela comum com (com restrições) em tipos de dados)
Gaius
5

  1. Uma coluna anulável não ocupa espaço se o comprimento da variável no SQL Server. O fato de ser NULL é armazenado no bitmap NULL . Você pode indexá-lo, se necessário, com índices filtrados, para ignorar colunas NULL.

  2. Adiciona complexidade quando você considera o ponto 1.

  3. Não. Difícil de pesquisar, analisar etc: você vai se arrepender mais tarde

Também depende do tamanho: isso será char (1000) por alguns bilhões de linhas? Ou tinyint para 100k linhas? Se este último considerar a complexidade adicional do ponto 2: não vale a pena.

gbn
fonte
Você tem uma referência de que uma coluna anulável que é nula não ocupa espaço. Eu sabia que, se era nulo ou não, estava armazenado no bitmap nulo, mas pensei em campos de comprimento fixo que os dados ainda estavam armazenados na tabela. O tipo de dados que vou usar para a maioria destes valores é dinheiro (para 8 bytes)
Matthew Steeples
1
@ Matthew Steeples: Eu disse que o comprimento variável não ocupa espaço. E para referência sqlskills.com/BLOGS/PAUL/category/On-Disk-Structures.aspx#p41 Como podem as linhas desses 8 bytes?
gbn 31/03
No momento, estamos em 500.000 linhas, mas vamos expandir (espero) a uma taxa de cerca de 1 milhão por dia da semana, quando estivermos funcionando corretamente.
Matthew Steeples 31/03
3

Com o SQL Server 2008, você tem a opção adicional de usar colunas esparsas, projetadas especificamente para a situação mencionada.

Eles têm o benefício adicional de que você pode visualizá-los como um objeto XML combinado usando XML COLUMN_SET ou referenciá-los individualmente e eles oferecem uma enorme economia de espaço.

Confira o seguinte artigo do blog para obter mais detalhes: http://www.sqlskills.com/BLOGS/PAUL/post/SQL-Server-2008-Sparse-columns-and-XML-COLUMN_SET.aspx

Jeff
fonte
-4

Uma quarta opção: não use tabelas. As tabelas são muito inadequadas para esse tipo de dados (de fato, para qualquer tipo de dados que não tenha sido ajustado à força em forma de tabela). Basta usar XML.

user1359
fonte
3
-1, pois, embora seja verdade que "não use tabelas" seja uma opção , a resposta está claramente declarando uma desonestidade contra as estruturas da tabela e, na verdade, não está enviando uma resposta útil.
Andrew Bickerton 31/03