Sim, aí sim : uma constraint de unicidade (mantida por um índice, ok) composta
por CNPJ + Fabrica + Local entrega + Doca + Tipo de programa aí Entendo que
fecha a questão de Integridade.... Com CERTEZA isso não tinha ficado claro,
não, mas ok...
Voltando á sua pergunta de PK, seguinte : as duas opções que vc disse estar
julgando seriam criar na tabela filha :
1. PK composta de CNPJ + Fabrica + Local entrega + Doca + Tipo programa
ou
2. PK composta por CNPJ + sequencial , combinada com UK composta por Fabrica +
Local entrega + Doca + Tipo programa
=> certo ? Meu primeiro ponto é que essas duas possibilidades NÃO VÃO TER DAR
as mesmas verificações de integridade, okdoc ? A primeira opção NÃO vai deixar
o mesmo CNPJ ter duas entradas da mesma Fabrica atendendo o mesmo Local na
mesma Doca com o mesmo Tipo, ENQUANTO a segunda opção VAI SIM DEIXAR isso
acontecer, desde que seja com dois Sequenciais diferentes.. Tá bem ?? Então,
minha primeira Observação é essa, é APONTAR que vc está modelando coisas
DIFERENTES com essas duas Possibilidades, só VOCÊ sabe as julgar e ver qual a
melhor...
Minha SEGUNDA observação é sobre performance/aplicabilidade de índice : se vc
tiver umá PK única composta de CNPJ + Fabrica + Local entrega + Doca + Tipo
programa, OBVIAMENTE isso implica que vc VAI ter um índice também composto por
esses campos : assim sendo , se vc for ter diferentes queries nessa combinação
(tipo, query filtrando por CNPJ + Fabrica, outra query filtrando por CNPJ +
Doca, ainda outra query filtrando por CNPJ + Tipo, etc), esse MESMO ÚNICO
ÍNDICE vai ser capaz de atender a essas diferentes queries.... Já se vc tiver
uma PK de CNPJ + sequencial e uma UK composta pelos outros campos, OBVIAMENTE
ISSO IMPLICA que vc VAI ter dois índices DIFERENTES, sim sim sim ??? Muitas
vezes o Oracle consegue fazer um INDEX MERGE dos dois numa só query MAS nem
sempre isso é garantido e VIA DE REGRA essa operação de INDEX MERGE não é de
grátis em termos de performance, ela TEM SIM um custo....
Blz ?
[]s
Chiappa
