[firebase-br] SQL Elegante

[Joao Luiz]

Thiago wrote:

> Não usar chaves compostas talvez faça sentido no oracle q tem um
> "artefato" chamado rowid. Mas para Interbase/Firebird não vejo
> vantagens nenhuma. É mais um índice a ser processado a cada transação.
> 
> 
> ----- Original Message ----- 

> eu concordo que padrões sao necessário, mas como o Magnun, sempre dou
> nomes significativos as colunas, usar id fica muito vago.
> > > * Chaves compostas nem pensar, use o id e o unique;
> realmente nao entendi porque nao usar chaves compostas, eu sempre
> usei e nunca tive problemas.

Bom... Caros colegas,

Nao querendo ser chato... nao entendo o problema da chave composta. Nao
to discordando propriamente, mas pedindo algum esclarecimento pra quem
defente, vi os comentarios dos colegas q preferem chaves compostas, mas
queria ver o esclarecimento do outro lado.
 
Explico: 

Por muito tempo trabalhei com dbase/clipper e a algum tempo uso SGBDs,
90% FB (embora quase mandei fazer uma camiseta: 100% Firebird hehehehe).

Naquela epoca (do dbase) eu usava um campo chamado CONTROLE para qq
tabela q fosse de movimentacao, ou seja, NFs, PEDIDOS, COMISSOES, ETC..
isso era muito util, pois esse numero nao precisava ser sequencial e se
o cara interrompesse a insercao nao ficaria com numero de nf ou pedido
perdido, pois esse era dado somente no final do processo. Hoje o cara
digita, fica tudo num ClientDataSet e dpois vai em uma transacao
registros pai e detalhe pro banco (eu acredito na ACID hehehehe em
doendes nao). Nao preciso mais do "controle", q considero um parente do
"ID".

Acontece q colocando um campo ID e colocando um indice "UNIQUE" terei
na maioria das tabelas 2 indices.

Ok, um campo numerico eh mais rapido q um campo string e uma chave
composta, mas ai nao estamos trocando o problema de lugar?

Sem falar que em algumas selects precisaremos fazer um join
desnecessario? (ex.:listas os items com suas respectivas NFs como
exemplo), lembro q para obter performance em alguns DBFs eram repetidos
dados da tabela PAI, eca, eca, eca, mas era um mal necessario.

Indices em demasia nao provocariam maior fragmentacao das paginas no bd?

Tah bom, pra uma replicação seria mais pratico e facil de fazer, mas
compensa?

Valeu e []´s

-- 
___________________________________
Joao Luiz          -         Linux user #159951
GRATIS eh POUCO: receba R$24,00 cada 100h navegando:
Orolix   :
http://cadastro.orolix.com.br/registro/?codcupom=0066399663943892
CresceNET: http://www.cresce.net/home.asp?id=256309
Algumas explicacoes : http://www.orolix.dahora.net
web  : http://www.jluizsc.pop.com.br