Chave composta - qual a melhor solução?

Banco de Dados
#1

Qual a melhor solução quando pretendo utilizar chave composta?
(Nas aplicações de Formulários, vou utilizar 1 campo do tipo SELECT para capturar valor de outra tabela que é chave composta)

[size=12pt][size=12pt]SOLUÇÃO 1 - usar os 2 campos como chave primária[/size][/size]

CLIENTES
[b]- firma

  • codigo[/b]
  • nome
  • morada

MOVIMENTOS
[b]- firma_de_movimento

  • numero_de_movimento[/b]
  • valor_de_movimento
  • cliente_firma
  • cliente_codigo

[size=12pt]SOLUÇÃO 2 - usar 1 campo (ID autoincrement) como chave primária e criar 1 indice composto de FIRMA+CODIGO[/size]

CLIENTES
- ID

  • firma
  • codigo
  • nome
  • morada

MOVIMENTOS
[b]- firma_de_movimento

  • numero_de_movimento[/b]
  • valor_de_movimento
  • cliente_id

E no campo SELECT fazer o lookup dos clientes pertencentes à firma actual [sm_global_firma].

Qual será a melhor solução para usar no Scriptcase?

#2

Eu ficaria com a Solução 1. A chave composta têm uma particularidade que eu gosto, que ela é N:N.

#3

Também cheguei a essa conclusão.
Thanks

#4

Eu já prefiro a solução 2, pois com o indice composto você garante a unicidade, porém para FK só tem um campo, caso você tenha que ligar uma aplicação com a outra basta passar um parâmetro, se for via get diminui a URL, além de facilitar nos comandos sql que só precisam receber um parâmetro na clausula where. Mas acredito que em ambas as soluções você consegue trabalhar, cada uma com suas vantagens e desvantagens.

#5

Vejo a dúvida com outros olhos.
1- A regra na modelagem relacional diz para utilizar a opção 1
2- A 2ª solução necessitaria ter um índice único para as FKs FIRMA e CLIENTE. A 2ª opção não é a mais apropriada.

#6

jlmonteiro, por favor informe a fonte de onde você consultou isto: 1- A regra na modelagem relacional diz para utilizar a opção 1

Poderia explicar melhor porque a 2ª opção não é a mais apropriada, ou é apenas sua opinião?
2- A 2ª solução necessitaria ter um índice único para as FKs FIRMA e CLIENTE. A 2ª opção não é a mais apropriada.

Pois até onde sei as duas técnicas podem ser empregadas e cada uma tem suas vantagens e desvantagens:
http://www.ora-ora.org/2012/11/chave-primaria-natural-ou-surrogate.html

#7

Eu costumo usar as duas opções… quando meu foco é a normalização do DB utilizo a segunda opção, quando a questão é desnormalizar (DWs) aí eu utilizo a primeira…

Mas via de regra é a segunda opção mais utilizada por mim.

#8

Do ponto de vista do Banco de Dados a segunda opção é a mais adequada.

De outro, pelo SC, a primeira opção pode ser melhor. Selects manuais em filtros por exemplo, quando as tabelas envolvidas estão normalizadas, fica mais trabalhoso.

Na primeira opção, vc tem dados redundantes na duas tabelas, o que para os DBAs mais puritanos, é um pecado de morte.

Mas, em qualquer um dos casos, use chave primária em ambas as tabelas. Toda tabela deve ter uma chave primária.