Re: [oracle_br] Re: Chave Primária
Eu também, acho que nos mais de vinte anos que trabalho com databases se vi uns dois ou três casos onde valia a pena Evitar índice muito longo (que são a natural decorrência de uma PK ou UK muito longa), foi muito Já que vc testou e não é o seu caso (dificilmente ia ser mesmo, as suas colunas parecem ser curtas e não são tantas assim) maravilha, via na tranquila na modelagem tradicional, mesmo... []s Chiappa
Re: [oracle_br] Re: Chave Primária
"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
Re: [oracle_br] Re: Chave Primária
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
Re: [oracle_br] Re: Chave Primária
"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
Re: [oracle_br] Re: Chave Primária
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
Re: [oracle_br] Re: Chave Primária
Bom dia Chiappa. Acho que não expliquei direito. 1º) Sim, na tabela cliente (pai) a pk é o CNPJ e na tabela fabrica (filha) vai ter um campo CNPJ com FK na tabela cliente. 2º) A PK da tabela fabrica seria composta por CNPJ + Sequencia 3º) O índice unique da tabela fabrica sera composto de CNPJ + Fabrica + Local entrega + Doca + Tipo de programa. Com esse índice acho que simulo uma chave primaria composta pelos mesmos campos Espero que tenha ficado mais claro. Emerson Em seg, 1 de jul de 2019 às 17:11, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Blz ? Então, primeira coisa se na tabela-pai a PK é CNPJ, para que a nova > tabela seja considerada FILHA da tabela-pai ela TEM que ter essa mesma > coluna CNPJ criada como FK e apontando pra PK da tabela pai, okdoc ?? A PK > da tabela-filha não importa pra essa funcionalidade... > Muito bem : isso dito,antes de discutirmos questões de acesso , índices, > e etc, plz ENTENDA que vc tem duas situações COMPLETAMENTE DIFERENTES aí!! > A contraint PK composta indica que qquer um dos valores (ou uma combinação > de todos exceto um) pode SIM se repetir nos outros registros, o que não > pode é duplicar TODOS da chave No seu exemplo, se vc tiver a PK > composta criada como CNPJ + FABRICA + LOCAL ENTREGA + DOCA + TIPO PROGRAMA, > isso quer dizer (por exemplo) que UM local de entrega pode ter N docas pra > mesma fabrica e mesmo CNPJ, tipo : > > |CNPJ |Fabrica|Local entrega|Doca|Tipo programa| > |53.358.644/0001-12|FAB01 |BRAS |D10 | TIPO1 | > |53.358.644/0001-12|FAB01 |VILA CARRAO |D10 | TIPO1 | > > ==> OU SEJA, os dois registros acima tão válidos porque NÂO FORAM TODOS OS > CAMPOS DA PK COMPOSTA que se REPETIRAM > > Agora, se vc criar uma constraint UNIQUE separada pra cada coluna, isso > indica que NA TABELA TODA, independente de qquer coisa, a coluna UNIQUE só > poderá ter um valor Imagine que a PK foi criada como CNPJ + SEQUENCIA > como vc propôs, e que as colunas FABRICA , LOCAL ENTREGA , DOCA e TIPO > PROGRAMA cada uma tem a sua UNIQUE KEY própria : suponha que eu tenho a > mesma situação acima, e inseri pro CNPJ 53.358.644/0001-12 inseri o > registro : > > |CNPJ |Fabrica|Local entrega|Doca|Tipo programa| > |53.358.644/0001-12|FAB01 |BRAS |D10 | TIPO1 | > > ==> Se eu tentar gravar (prum outro CNPJ ou pro mesmo com outra sequência, > tantofaz) um outro registro para (digamos) LOCAL DE ENTREGA = BRAS kaput, a > constraint UNIQUE do LOCAL DE ENTREGA ** não vai me deixar ** fazer isso... > Com as constraints UNIQUE separadas, isso significa que NENHUM OUTRO CNPJ > poderia ter a fábrica FAB01, ou o local de entrega BRAS ou a doca D10 !!! É > isso que significa uma constraint UNIQUE particular pra cada coluna... Faz > sentido isso na sua modelagem ?? > Ou seja, essas duas construções ** ABSOLUTAMENTE NÃO SÃO ** duas maneiras > de fazer a mesma coisa, como vc parece dar a entender : na verdade são > coisas COMPLETAMENTE DIFERENTES, são Validações feitas de maneira > completamente DIFERENTE, okdoc ??? > > []s > >Chiappa > >
