Por favor, RFC 1855!
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.
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/
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 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.
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.
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.
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.
Por exemplo — um exemplo bobo, meio surreal, mas já visto — quando um
número de conta bancária inclui informações sobre o tipo de conta; ou
quando um dígito verificador é registrado no mesmo atributo do número.
> 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.
> 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.
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.
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
xmpp:[EMAIL PROTECTED] +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
