"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...."
Pra dizer a verdade Chiappa, nunca tive problemas de performance usando PK's com junção de vários campos. O questionamento foi apenas pra constatar as melhores praticas de modelagem de dados. Mas como a "custo" não parece ser grande, e no meu caso, não senti diferença nenhuma, vou continuar usando a modelagem mais clássica. Obrigado pelas respostas sempre prestativas. []s Emerson Em ter, 2 de jul de 2019 às 18:36, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > 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 > >
