Menu de navegação

[CarlosParticipante]

Olá pessoal,
Basicamente o conceito de Surrogate Key é o mesmo que o Design Pattern Identity Field (Martin Fowler) que preza por utilizar uma chave que não tenha nada a ver com o negócio. Seja ID, GuiID, etc.
Eu sou desenvolvedor .Net e essa pratica é muito comum em desenvolvedores .Net ou Java pois facilita muito a Orientação a Objetos.
Particularmente eu curto e sempre trabalhei desse jeito (exceto para tabelas de dominio/sistema).
Tabela de Domínio/Sistema/Lookups = Tabelas auxiliares que não possuem cadastro e geralmente são utilizadas para preenchimento de combos. A inclusão de itens é feita geralmente por alguém de TI. Ex: Tabelas de estado civil, tabelas de status, tabelas de unidade federativa

Todas as demais tabelas de cadastro, utilizaria ID como PK ao invés de Chave Natural, onde os atributos de negócios não repetidos seriam controlados através de Indice Único.

Exemplo Cenário 1:
TAB_UF (Unidade Federativa) – Tabela de dominio alimentada por alguém de TI (DBA, AD, etc)
#CD_UF – SP (Chave Primária)
DS_UF – São paulo

TAB_CLIENTE (Clientes) – Tabela populada pelo usuário através de tela
#ID_CLIENTE – 1 (Chave Primária com Sequence)
NM_CLIENTE – FULANO DA SILVA
TP_PESSOA – F (CheckConstraint F=Fisica, J=Juridica)
CD_UF – SP
FL_STATUS – A (CheckConstraint A=Ativo, I=Inativo)

A empresa que trabalho decidiu adotar Surrogate Key para TODAS as tabelas e suspendeu o uso de CheckConstraints e consequentemente Enum no C#.
Ou seja, para implementar o mesmo exemplo acima, as tabelas ficariam conforme abaixo:

Exemplo Cenário 2:
TAB_UF (Unidade Federativa) – Tabela de dominio alimentada por alguém de TI (DBA, AD, etc)
#ID_UF – 1 (Chave Primária com sequence)
CD_UF – SP (Índice único)
DS_UF – São paulo

TAB_TIPOPESSOA (Tipo de Pessoa)-Tabela de dominio alimentada por alguém de TI (DBA, AD, etc)
#ID_TP_PESSOA – 1 (Chave Primária com sequence)
CD_TP_PESSOA – F (F=Física, J=Juridica)
DS_TP_PESSOA – Física

TAB_STATUSPESSOA (Status da Pessoa)-Tabela de dominio alimentada por alguém de TI (DBA, AD, etc)
#ID_ST_PESSOA – 1 (Chave Primária com sequence)
CD_ST_PESSOA – A (A=Ativo, I=Inativo)
DS_ST_PESSOA – Ativo

TAB_CLIENTE (Clientes) – Tabela populada pelo usuário através de tela
#ID_CLIENTE – 1 (Chave Primária com Sequence)
NM_CLIENTE – FULANO DA SILVA
ID_TP_PESSOA – 1 (ForeignKey)
ID_UF – 1 (ForeignKey)
ID_ST_PESSOA – 1 (ForeignKey)

Detalhes: Como esses IDs são Sequences, estes poderão ser diferentes entre os ambientes de DEV, HOM e Produção.

Dúvidas?
1) É correto/viável usar surrogate key para tudo ? Inclusive para tabelas de dominio como: Status, Estado Civil, UF?

2) Imaginem uma situação em que eu tenha uma Procedure e precise fazer um Case por Status ou Tipo de Pessoa. Com o primeiro cenário é simples, mas no segundo é complicado pois é tudo ID.

3) O que acham sobre isso? Vale a pena usar ID pra tudo ou fazer um mix conforme o cenário 1?

Obrigado,
Carlos Araujo

[rmanParticipante]

@carlosdev

Detalhe- Esses IDs não devem ser diferente na base de DEV, HOM e Produção, e mesmo que fossem diferentes isso não deveria mudar o comportamento do sistema.

1- Eu trabalho com surrogate key pra tudo, e não vejo problemas. Eu já fui desenvolvedor e hoje sou DBA, acredite isso facilita muito para o DBA, o modelo de dados fica mais nítido e fácil de entender.

2- Creio que isso não aumenta tanto a complexidade, é questão de costume, basta uma junção com a tabela e continua da mesma forma, continue comparando com o tipo e não com o ID, o ID no seu código não representa muita coisa.

3- Creio que é questão de padrão, o importante é que todos utilizem o mesmo.

[CarlosParticipante]

Olá rman,
obrigado pelo feedback.
Concordo que se usar Surrogate para tabelas de dominio, os IDs deveriam ser o mesmo em todos os ambientes e não deveria utilizar Sequence.

Sobre a complexidade da junção (join) até que não é alta, mas pense no caso de situações que aceita 2, 3 estados (ex: SUCESSO/FRACASSO, MASCULINO/FEMININO, PAR/IMPAR). Vocês vão criar inúmeras tabelas de dois registros com a descrição destes estados. Se você precisar fazer uma consulta em uma tabela que armazene a coluna de FK destas tabelinhas -ex: CLIENTE, com a coluna ID_SEXO – você sempre precisará ficar fazendo JOINS para entender qual o SEXO do funcionário.

Imagine inclusive que você tem uma indicador que só aparece em uma única tabela do sistema. Se seguir esta lógica, você será obrigado a criar mais uma uma destas tabelinhas somente para guardar o status da mesma.

Imagine também o cenário de insert em lote através de arquivo texto, por exemplo 30000, 50000 linhas ou mais.
No qual a tabela a ter os registros inseridos possuem 3 campos de dominio: Status (Ativo, Inativo), TipoProduto (Nacional, Importado), Disponivel (Sim, Não).
A planilha contém apenas os domínios e não os IDs dos dominios.
Imaginou o custo para se inserir todas as linhas? Pois para cada linha, precisarei localizar o ID de cada domínio antes de realizar a inclusão.

Você acha que todo esse trabalho vale a pena se temos um recurso muito importante no Oracle que são as CheckConstraints?

Obrigado mais uma vez por contribuir com sua opinião e abraço,
Carlos Araujo

[rmanParticipante]

@carlosdev

Isso é questão de paradigma. O que se economiza em banco de dados você gasta em linha de código. Por exemplo, se não está armazenado no banco as descrições dos domínios, você terá que fazer isso manualmente via código, aumentando a complexidade.

Tabelas de domínios são pequenas, espaço para armazenar isso também não deve ser problema.

Sobre importação, é só fazer o tratamento do dados antes de importar.

Checks eu utilizo geralmente para garantir a integridade de um dado em que a regra de negócio é mais complexa e que não é possível criar uma tabela de domínio. Exemplo: o valor do desconto não deve ultrapassar 30% em compras abaixo de R$ 100,00.

Se você tiver abertura, apresente o seus argumentos e tente convencer o autor da proposta. Qual a opinião da sua equipe sobre isso? Fazer o que gerente de projeto manda só por que ele acha melhor, não ajuda em nada, quem implementa sabe o que é melhor pro projeto.

[Fábio PradoParticipante]

Carlos,

Eu sou a favor de usar uma abordagem mista. Para o seu caso eu usaria Natural Key na tabela CD_UF. Quer saber porque? Leia o artigo Surrogate Keys vs Natural Keys for Primary Key?.

[]s

[Autor]

Posts