Olá Leandro, eu sabia que a thread ia dar panos para mangas.... Bem
vamos lá: Em Sex, 2007-08-10 às 11:26 -0300, Josir Gomes escreveu:
> O que eu quero dizer é que uma chave que hoje faz todo sentido de ser
> candidata deixará de ser daqui a 5 anos, por conta das mudanças
> externas impostas pelo ambiente. E quanto mais tempo ela tiver
> existido, maior será a dor de cabeça será para ela ser mudada.
A questão hoje é que eßas dores de cabeça são muito menores que os de
não ter chaves candidatas declaradas.
Por exemplo, temos os ON UPDATE CASCADE, que ajudam muito.
Quando eu falei em mudanças Leandro, eu não quis falar no conteúdo da chave mas
no próprio conceito, isto é,
quando o ambiente nos diz que a chave não representa mais unicamente um
registro. Nesse caso, temos que alterar a modelagem. Quer um exemplo:
Uma empresa sempre trabalhou com NFs com a chave (FILIAL SERIE NUMERO). Entretanto, com o advento das NF eletrônicas, a numeração foi alterada e não existe mais o conceito de série e além disso o número passou de 6 para 10 algorismos. Sem falar que a numeração vai começar de novo do zero ! Já pensou no transtorno?
Por outro lado, não ter uma chave primária gera problemas graves de
difícil resolução ? vide por exemplo
http://www.commandprompt.com/blogs/joshua_drake/2007/08/surrogate_versus_natural_primary_keys/
Achei o exemplo do site bem inocente. Ora, e se for obrigatório ter 2 Joshua
Drakes no banco??? Como resolver?
No caso da exclusão, vc tem que dar recursos visuais para que o usuário possa
selecionar qual a pessoa que ele quer. Na verdade, no mundo real, nunca se iria
excluir uma pessoa do banco. O correto seria atribuir um status de Inativo para
ele para preservar todo o histórico transacional dessa pessoa. Por isso achei
um exemplo muito simplista.
Uma situação que já encontrei mais de uma vez é que definem-se somente
chaves artificiais, e presto, têm-se toneladas de dados multiplicados,
não apenas duplicados. E aí cada chave candidata a ser implementada
para prevenir o crescimento do problema exige a resolução do passivo
histórico mais o teste do aplicativo que está colaborando com o
problema.
Se existem dados duplicados, então a modelagem foi mal feita. A chave candidata
tem que permanecer apenas na tabela que é identificada por ela. Mesmo quando
ela caducar, ou seja, quando ela deixar de dar unicidade ao registro, ela deve
permanecer apenas na tabela de origem.
> Se vc já modela todas (ou quase todas) as tabelas do sistema com
> surrogate keys, vc evita uma gama enorme de problemas que surgirão,
> aumentando o ciclo de vida do seu modelo, enfim fazendo que se gaste
> menos para implementar mudanças.
Vide contra-exemplos acima?
Se você quiser manter a integridade conceitual das chaves candidatas,
que é fundamental, mais a conveniência da chave artificial, vai ter
alguns problemas.
1) A chave artificial será a primária, o que vai obscurecer a
informação semântica do modelo e forçar mais junções. Definir a
artificial como alternativa faz pouco sentido, a menos que não haja
absolutamente chave candidata simples.
1. Opa! Informações semanticas devem ser mantidas no modelo lógico, não no
físico!!!
2. Concordo entretanto que as surrogate keys forçam mais junções mas o custo
delas é muito menor que o custo de alterações no modelo.
2) A chave artificial engordará o modelo, tornando-o mais complexo e
indireto, o armazenamento em disco, a atividade de E/S e o consumo de
cache, tanto pela existência de um atributo a mais na tabela quanto de
um índice a mais, o qual tem de ser não apenas lido como também escrito
? e isso não substituindo as chaves candidatas, mas suplementando-as.
Concordo. Mas é um preço bem barato a ser pago pela maior reusabilidade do
modelo.
Existe apenas uma vantagem real:
a) Por causa de uma restrição arbitrária do SQL, no caso de uma tabela
relativamente menor que é mãe de uma ou mais tabelas significativamente
maiores, e realmente enormes (coisa de GiB ou TiB), a exportação de uma
chave estrangeira artificial simples pode ser mais econômica em
armazenamento, cache e E/S que o de chaves candidatas, *se* não houver
absolutamente chave candidata simples.
Não acho que essa seja uma vantagem significativa. Nas máquinas atuais, esse
custo é ínfimo.
De qq forma, em modelos reais complexos, é difícil encontrar chaves candidatas
com um único atributo.
Note que muitas das inconveniências atribuídas a chaves naturais
decorrem não de serem naturais mas de má análise; é o caso quando se
coloca na chave informações acessórias, por exemplo derivadas da chave
em vez de realmente sendo parte dela, ou juntando-se num atributo coisas
que são logicamente mais de um atributo.
Nem levei em conta o fato da má análise. Sempre assumi na discussão que a chave
candidata era resultado de uma análise correta. O problema, como já tinha dito
anteriormente, é que o correto ontem deixa de ser correto no futuro por conta
das mudanças organizacionais !
> Se vc analisar os modelos do SAP R3, ou do Oracle Applications, vc
> verá que eles são recheados de Surrogate keys. Só assim, eles
> conseguem responder por uma gama enorme de requisitos que chegam a
> todo instante.
Nem a SAP nem a Oracle são parâmetro de modelagem. A Oracle em
particular é bem conhecida por não saber a diferença entre SQL e
relacional, e bagunçar até o SQL, além de ter modelos inconsistentes.
Vide mesmo o dicionário de dados do SGBD deles.
Vc não pode comparar a modelagem do dicionário de dados com a de um ERP. São
objetivos diferentes.
A modelagem do dicionário de dados do Oracle, por exemplo, visa máxima
performance em detrimento de um melhor entendimento. Agora dizer que os ERPs
mais utilizados no mundo não são parametros para modelagem, acho um pouco
exagerado.
> Sugiro que vc dê uma olhada no livro do Scott Ambler "Refactoring
> Databases" - lá ele detalha em minúcias o que eu tentei explicar aqui.
Conheço os argumentos, e já vi problemas dos dois lados? mas me assusta
recorrer a referências ?pragmáticas?, que tendem a se limitar a
problemáticas geradas pelo padrão SQL que é ruim ou mesmo por suas
implementações que são piores ainda. Melhor recorrer a textos mais
conceituais, como os do Date, do Darwen, do McGoveran e do Pascal que
sempre cito.
Não entendi: quem cita SQL em todo a teoria relacional não é o Date ???
Inclusive, em artigos posteriores ao livro, Date citou positivamente inúmeras
vezes as surrogate keys (sem dar preferência para elas). Mas concordo com vc,
sou pragmático. Muito pragmático.
Por exemplo, os conceitos centrais são de normalização, não de
refatoração. Refatoração tem a ver apenas com problemas físicos, de
implementação; não deveria dizer nada contra a normalização.
Peraí, em nenhum momento falei que não tinha que ter normalização!
Dá uma olhada com calma no livro dele pois ele insiste na normalização o tempo
todo.
Também acho que temos conceitos diferentes sobre o conceito de refatoração.
Refatorar é alterar um modelo sem alterar a funcionalidade do mesmo com o
objetivo de otimizá-lo. Geralmente, se usa em programação mas o conceito é mais
genérico que isso.
Definitivamente, viemos de escolas de pensamento diferentes :)
Mas entendo o seu ponto de vista.
Um abraço,
Josir Gomes
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
