Seguem as respostas : ' 1. PK composta de CNPJ + Fabrica + Local entrega + Doca + Tipo programa" Ok, é isso.
"2. PK composta por CNPJ + sequencial , combinada com UK composta por Fabrica + Local entrega + Doca + Tipo programa" Essa UK seria composta de CNPJ + Fabrica + Local entrega + Doca + Tipo programa. ' => olhando o texto acima, vc afirma que na verdade ia criar a UK tal como a primeira opção de PK : se o desejado é garantir unicidade para a combinação CNPJ + Fabrica + Local entrega + Doca + Tipo programa , a partir do momento que vc criou uma PK ** ou ** uma UK com essa combinação de campos, vc garantiu essa unicidade, não faz sentido então vc querer ter um PK com CNPJ + sequencial JUNTO com a UK com os outros campos todos... Acho que a sua dúvida então é quais diferenças vc ia ter se criasse a constraint necessária como PK versus se criar como UK, mas sempre com todos os campos ?? Se for isso, a resposta é simples : basicamente NENHUMA diferença... E entenda que tanto a PK composta quanto a UK composta teriam um único índice composto, ok ?? ' Lembrando, que esse assunto todo, foi pq jã vi em muitos lugares o pessoal desaconselhando usar PK's muito longas, compostas de muitos campos (essas sugestões não necessariamente se referiam ao Oracle, ok?), aconselhando transformar esses campos em um sequence. Por isso vim aqui perguntar, onde só tem especialista em Oracle, se o mesmo se aplicava a ele. ' OK : sim, falando em termos de performance qquer que seja o SGBD quanto mais colunas houver na chave de um índice, mais esforço vai ser necessário para Ordenar esse índice, para manter as suas entradas, sim, sim.... É ** incerto ** pra nós, porém, aqui de fora, sem conhecer NADA do seu ambiente, sabermos se esse Overhead a mais decorrente da chave composta longa VAI ser significativo pro seu hardware, pro seu database, pro seu volume de dados... Vc não o diz mas eu IMAGINO que essas refs que sugerem trocar a combinação das colunas (Fabrica + Local entrega + Doca + Tipo programa, no seu caso) por uma sequence deve ser uma modelagem no estilo : digamos que eu tenho uma tabela DETALHES_ENTREGA composta por ID_ENTREGA, Fabrica , Local entrega, Doca e Tipo, aí (voltando ao meu exemplo anterior) vc cadastrou nessa tabela : ID_ENTREGA|Fabrica|Local entrega|Doca|Tipo | 0001 |FAB01 |BRAS |D10 | TIPO1| 0002 |FAB01 |VILA CARRAO |D10 | TIPO1| aí na sua tabela-filha, vc NÂO teria essas colunas Fabrica,Local entrega, Doca e Tipo e teria só a coluna ID_ENTREGA, que seria FK dessa tabela DETALHES_ENTREGA e ao mesmo tempo seria uma UK junto com CNPJ... Aí vc garantiu que um CNPJ não pode repetir a mesma conjunção de Fabrica, Local entrega, Doca e Tipo, que ENTENDO é o Objetivo, e fez isso SEM um índice composto.... Yep, em alguns casos isso FAZ SENTIDO SIM, não importa qual seja o seu SGBD, o Oracle Absolutamente Não É Diferente de outros SGBDs quando se fala de índices b*tree : como em qualquer SGBD, cada entrada no índice b*tree TEM que ser ordenada, vc TEM que ter branchs para permitir poda binária, etc, e essas coisas TEM SIm um overhead... Minha Sugestão é : faça TESTES o mais precisos possíveis aí na sua máquina/noseu ambiente, com o seu volume de dados esperado, e VERIFIQUE se esse overhead JUSTIFICA 'truques' de modelagem como identificar a combinação de N campos por um ID sequencial artificial OU se não, um simples índice composto alimentando uma PK ou UK composta te atende bem.... []s Chiappa
