"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" *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.* " => 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..." *Fazendo a UK composta como descrito acima, não acredito que haveria problemas com a funcionalidade..........eu acho. E ela se comportaria exatamente como uma PK compostas pelas mesmas chaves.* "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.... " *Pelo que entendi, a PK composta pelos campos seria melhor então. Teria um trabalho a menos para o banco.* 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. Emerson Sanches Analista de Sistemas Em ter, 2 de jul de 2019 às 09:42, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > 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 > >
