Quais são as melhores práticas em relação às tabelas de pesquisa em bancos de dados relacionais?

As tabelas de pesquisa (ou tabelas de código , como algumas pessoas as chamam) geralmente são uma coleção dos possíveis valores que podem ser fornecidos para uma determinada coluna.

Por exemplo, suponha que tenhamos uma tabela de pesquisa chamada party(destinada a armazenar informações sobre partidos políticos) com duas colunas:

• party_code_idn, que contém valores numéricos gerados pelo sistema e (sem significado no domínio comercial ) funciona como substituto da chave real.
• party_code, é a chave real ou "natural" da tabela porque mantém valores que possuem conotações no domínio comercial .

E digamos que essa tabela retenha os dados a seguir:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

A party_codecoluna, que mantém os valores 'Republicano' e 'Democrata', sendo a chave real da tabela, é configurada com uma restrição ÚNICA, mas eu opcionalmente adicionei party_code_idne defini-a como a PK da tabela (embora, logicamente falando , party_codepode funcionar como a PRIMARY KEY [PK]).

Questão

Quais são as práticas recomendadas para apontar para valores de pesquisa de tabelas de transação ? Devo estabelecer referências à CHAVE ESTRANGEIRA (FK): (a) diretamente ao valor natural e significativo ou (b) aos valores substitutos?

Opção (a) , por exemplo,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

possui as seguintes propriedades ¹ :

1. Legível para o usuário final (+)
2. Fácil de importar e exportar entre sistemas (+)
3. Difícil alterar o valor, pois precisa de modificação em todas as tabelas de referência (-)
4. Adicionar novo valor não é caro (=)

Eu acho que é quase como " passar por valor ", desenhar uma analogia da chamada de função no jargão de programação de aplicativos.

A opção (b) , por exemplo,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

tem as propriedades abaixo:

1. Não legível para o usuário final (-)
2. Difícil importar-exportar , pois precisamos desmarcá-lo (-)
3. Valores fáceis de alterar, pois armazenamos apenas referências nas tabelas de transações (+)
4. Adicionar novo valor não é caro (=)

É muito semelhante a " passagem por referência ", se comparado à chamada de função na linguagem de programação de aplicativos.

A importação-exportação também pode ser feita de uma maneira diferente, ou seja, apenas preenchendo a tabela de consulta novamente e, em seguida, re-semeando a coluna substituta. Espero estar acertando, isso é algo que acabei de ouvir como uma possibilidade.

_{1. Nota que +, -e =indicam o benefício dessas propriedades.}

Questão

Muito importante: existe uma diferença entre uma tabela de pesquisa (ou código ) e uma referência FK se apenas usarmos a última abordagem? Eu acho que eles funcionam da mesma forma.

Recursos relacionados

• Quão importante são as tabelas de pesquisa?

• Práticas recomendadas com tabelas de código ou pesquisa

• Práticas recomendadas de tabelas de pesquisa Tabelas ou enumerações de banco de dados

Por IDN, Acho que você quer dizer um IDENTITY, SEQUENCEou AUTO_INCREMENTcampo? Você deve dar uma olhada aqui e aqui .

Observe a seção 5 (Uso incorreto dos valores de dados como elementos de dados) da primeira referência, abaixo da figura 10

É claro que você pode ter uma tabela separada para os vendedores e referenciá-la usando uma chave estrangeira, de preferência com uma chave substituta simples, como sales_person_id, mostrada acima.

Portanto, esse especialista pensa que você deve "deferir" as chaves substitutas. É realmente uma técnica SQL básica e não deve causar problemas no seu SQL do dia-a-dia. Parece que há um erro na figura 10 - o sales_person em SalesData deve ser uma chave substituta (ou seja, um número), não um texto. Estou deduzindo isso da citação acima.

O que você deve evitar a todo custo é a tentação (muito comum para programadores de banco de dados iniciantes) de cometer o erro descrito na seção (1) Tabelas de pesquisa comuns. Isso geralmente é chamado de abordagem MUCK ( Massively Unified Code Key ) (não por acidente :-), notadamente por Joe Celko , também sarcasticlly conhecido como OTLT - One True Lookup Table ) e leva a todos os tipos de dificuldades. Programadores iniciantes parecem achar que um único código / pesquisa / qualquer tabela é "mais limpa" e será mais eficiente quando nada puder estar mais longe da verdade.

A partir da segunda referência acima:

A normalização elimina os dados redundantes, tornando assim a tarefa de impor a integridade dos dados muito mais simples, mas o processo de criação de um MUCK é algo totalmente diferente. como demonstrarei, menos tabelas não são iguais à simplicidade.

Você também pode querer dar uma olhada no paradigma relacionado ao EAV ( Entity Attribute Value ) com o qual trato aqui .

Existe uma terceira abordagem que tem algumas das vantagens de suas duas opções - coloque um código real na tabela de códigos. Com isso, quero dizer uma sequência curta de caracteres que captura a essência de todo o valor e é única. Para o seu exemplo, pode ser

Idn: 1
Name: Democrats
Code: D      (or DEM)

O Código é transportado para tabelas transacionais como uma chave estrangeira. É curto, inteligível e um pouco independente dos dados "reais". Alterações incrementais no nome a não sugerem uma alteração no código. No entanto, se os republicanos se decidirem em massa , uma mudança de código pode ser necessária, com os problemas decorrentes que uma identificação substituta não teria.

Este estilo foi denominado uma codificação de abreviação. Eu posso recomendar a escrita de Celko sobre isso. O Google books contém vários exemplos. Procure por "codificação Celko".

Outros exemplos: codificações de 2 ou 3 letras para países, codificação de 3 letras (GBP, USD, EUR) para códigos de moeda. Curto, auto-explicativo e sem alteração (e existe um ISO para eles).