RES: [firebase-br] Indices compostos..

Flavio Yamil yamil3 em brturbo.com.br
Seg Mar 14 17:33:50 -03 2005


Comentando...

>Mas o controle de "Auto-incrementos" do Firebird nos permite a contornar 
>facilmente esta operação colocando o seguinte na Trigger:

>if ((new.pk is null) or (new.pk = -1)) then
>  new.pk = gen_id (...

>Isso resolveria o problema citado acima. Sem contar que usar de um campo 
>auto-incremento (daqueles onde não seria possível o controle citado acima) 
>em tabelas master, é meio que suicídio. Justamente para casos como este. 
>Você não acha?

Realmente, Francisco. O Firebird (com generators) contornaria o problema
testando se o valor é nulo ou não. 
É que eu venho do SQL Server, onde o conceito de auto-incremento é meio
diferente, e não há essa flexibilidade.

De qualquer forma, essa é uma dúvida que sempre tive... Por que não usar
campos chave únicos? São muito mais práticos!
Me lembro que nos livros sobre análise de sistemas ou banco de dados, com
aquelas regras de normalização, sempre pregam para usar chaves compostas. É
bem verdade que na prática o negócio é bem diferente do que na teoria, mas
sem dúvida é uma bela questão. Vou dar uma olhada nos livros pra ver o que
os autores dizem.

>A minha maior aversão a Chaves compostas é que se por acaso ela vier a ser 
>master de outra tabela, eu terei de ter o mesmo indice composto na tabela
>de 
>detalhe... quando talvez eu não precise disso.

Sem dúvida, um índice composto é mais custoso do que um índice com campo
único.


Se alguém tiver algo a acrescentar, por favor, contribuam...

Abraços

Flavio Yamil

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Francisco Thiago
Enviada em: segunda-feira, 14 de março de 2005 14:31
Para: FireBase
Assunto: Re: [firebase-br] Indices compostos..

Argumentando:

>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.

Mas o controle de "Auto-incrementos" do Firebird nos permite a contornar 
facilmente esta operação colocando o seguinte na Trigger:

if ((new.pk is null) or (new.pk = -1)) then
  new.pk = gen_id (...

Isso resolveria o problema citado acima. Sem contar que usar de um campo 
auto-incremento (daqueles onde não seria possível o controle citado acima) 
em tabelas master, é meio que suicídio. Justamente para casos como este. 
Você não acha?

A minha maior aversão a Chaves compostas é que se por acaso ela vier a ser 
master de outra tabela, eu terei de ter o mesmo indice composto na tabela de

detalhe... quando talvez eu não precise disso.

Quanto ao arquivo morto, teria que pensar mais um pouco e pensar nas 
possíveis estruturas das tabelas para te dar uma resposta com precisão... 
mas acredito que não faça muita diferença não


 Francisco Thiago de Almeida
Enter&Plug Informática
Divisão: Desenvolvimento e Banco de dados
MSN: thiago em enterplug.com.br


----- Original Message ----- 
From: "Flavio Yamil" <yamil3 em brturbo.com.br>
To: "'FireBase'" <lista em firebase.com.br>
Sent: Monday, March 14, 2005 2:11 PM
Subject: RES: [firebase-br] Indices compostos..


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


-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Ivan
Enviada em: segunda-feira, 14 de março de 2005 07:55
Para: lista em firebase.com.br
Assunto: Re: [firebase-br] Indices compostos..

A minha professora tb disse que uma PK era necessaria, mas no mundo real
a coisa é bem diferente...



Francisco Thiago escreveu:
> Puxa! Seis campos!
>
> E quantos campos tem a sua tabela?
>
>
> E complicada esta questão de PK Lembro da minha professora de Análise
> dizendo que os campos que fossem PK's deveriam identificar unicamente a
> linha em toda a tabela... Pensando nisso, acho que num caso onde você já
> tem uma chave auto-incremento, demais campos como PK seriam
> desnecessários (oras, não vai repetir nunca!). Agora, PK são
> programaticamente diferentes de unique keys... Uma diferença sutil
> mas... (sendo redundante) que faz diferença
>
> Francisco Thiago de Almeida
> Enter&Plug Informática
> Divisão: Desenvolvimento e Banco de dados
> MSN: thiago em enterplug.com.br
>
>
> ----- Original Message ----- From: "Ivan"
> <ich em via.com.br>
> To: <lista em firebase.com.br>
> Sent: Friday, March 11, 2005 12:51 PM
> Subject: Re: [firebase-br] Indices compostos..
>
>
>> Eu uso tabelas com até 6 campos no pk, é muito bom pra performance só
>> da um pouco mais de trabalho pra implementar
>>
>> Fausto escreveu:
>>
>>> Bom dia..
>>>
>>> Estou com uma dúvida ref. a indices compostos no FB, pois tenho visto
>>> que as opiniões divergem, uns dizem que não há problema, já outros
>>> dizem para evitar ao máximo.
>>>
>>> Gostaria que os amigos opinassem tendo como exemplo uma tabela de
>>> comissões onde entre outros campos temos:
>>> NumeroVenda  (PK)
>>> Numeroitem     (PK)  CodigoVendedor
>>> DataMovto
>>> CodigoProduto
>>> ValordaVenda
>>> ValorComissao
>>>
>>> Neste exemplo a PK já vai ser composta, pois a comissão esta no
>>> produto, e para consultas teria um outro indice secundário que seria
>>> o codigo do vendedor + a data do movto. Como vcs podem notar estou
>>> meio perdido quanto a utilização de indices compostos, afinal de
>>> contas esta técnica é segura?
>>>
>>> Fausto ______________________________________________
>>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>>> Para editar sua configuração na lista, use o endereço
>>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>>
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
>> Para editar sua configuração na lista, use o endereço
>> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>>
>
>
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>


______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br



______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço 
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br





______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
Para editar sua configuração na lista, use o endereço
http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br






Mais detalhes sobre a lista de discussão lista