RES: [firebase-br] Indices compostos..

[Josauro S.J.]

Usar sempre chaves PK com campos simples numéricos unicos.
Tudo depende de uma boa estrutura do sistema, se for por comodismo apenas os sistema tendem a ser uma eca, com uma boa analize todos os problemas podem ser solucionados, uso a opção de expurgar a vida toda de um cliente nessa extrutura, quando o cliente é levado para o arquivo morto, ele cria a sua própria sequencia no arquivo morto, se for retornado retorna na sequencia atual e não onde estava, pois uma vez que a vida dele toda o acompanha as chaves tambem o fazerm, e ainda reaproveito todo o codigo deletado ou seja não deixo buraco nas sequencias, a chave PK é interna e de uso do sistema, o cliente tem a sua propria sequencia que pode definir como entender melhor.
Como disse existe o correto de ser feito e o mais comodo, tudo depende do que se queira para o seu sistema, algumas horas a mais de analize e programação valem a pena para ter um sistema bem estruturado e de boa performanse o resto é deixar para estourar a bomba mais tarde....
Lógico cada desenvolvedor escolhe como fazer dependendo de onde trabalhe e para quem trabalhe...

Josauro S.J.
josauro em casasoft.inf.br
> Existe outra questão com relação a PKs compostas ou únicas (com campo
> auto-incremento).
>
> Imagine que você tivesse as seguintes tabelas, todas com PKs
> auto-incremento.
>
> CLIENTE
> PEDIDO
> PEDIDO_ITEM
>
> Se por um acaso, sem querer, um usuário exclui um CLIENTE, o SGBD vai
> excluir todos os registros correspondentes nas tabelas PEDIDO e
> PEDIDO_ITEM.
> Então, o usuário entra em contato com você e informa o desastre, afim de
> que
> você (com seus super poderes de DBA) recupere os registros do backup.
>
> Neste momento, se você tiver as PKs definidas como campos auto-incremento,
> provavelmente terá dificuldades em restaurar os registros, mas, se você
> tem
> PKs compostas, a tarefa fica bem mais tranqüila.
> Neste exemplo usei apenas três tabelas, mas na realidade poderia envolver
> dezenas de tabelas, o que complicaria ainda mais a situação.
>
> Outra vantagem das chaves compostas, seria a facilidade "retirar"
> registros
> antigos da base, para armazenar em um banco de "arquivo morto", por
> exemplo.
> Isso imaginando um sistema que gere milhares de registros por mês, durante
> anos, a base tende a ficar inchada com registros que praticamente não
> seriam
> mais acessados. Nesse caso, seria boa prática realizar uma "enxugada" na
> base de produção para que ganhe performance nos backups, selects, etc...
> Com chaves compostas fica fácil retirar e retornar registros na base de
> dados.
>
> Espero ter ajudado
>
> Flavio Yamil
>