Re: [oracle_br] Re: Criação de Índices em Chaves Estrangeiras
Adriano Sobre os "joins", não é bem assim... Se houver um índice para a FK, é uma "alternativa" a mais para o CBO considerar. Pode ser que seja vantajoso e tenha um bom ganho, ou pode ser que nem seja utilizado. Para esse caso dos "joins", acho que o melhor seria **testar** o desempenho e plano de execução sem índice e com índice, com algumas variações desses joins. [ ]'s André Em 31/01/08, Adriano de Oliveira <[EMAIL PROTECTED]> escreveu: > > Foi exatamente o que o Chiappa disse... > Se vc tem update na PK da tabela mae, ou delete em cascata na tabela mae, > vc deve usar um indice na FK da tabela filha. > > Agora, outra duvida é quanto a joins... > Se eu utilizar join em um select amarrando a tabela filha com a pai, > eu não precisaria criar um indice na FK entao... até pq nesse caso > a busca é inversa.. ou seja, a cada registro da tabela filha o BD > vai procurar na tabela pai o registro correspondente àquela FK, > e na tabela pai já existe índice por ser PK. > Correto??? > > []'s > Adriano > > - Original Message - > From: rei_do_delphi > To: oracle_br@yahoogrupos.com.br > Sent: Thursday, January 31, 2008 7:39 AM > Subject: [oracle_br] Re: Criação de Índices em Chaves Estrangeiras > > Chiappa, eu não entendi uma coisa só, supondo que esta tabela Mãe > seja uma tabela com um alto índice de inserts e deletes, para o > insert, um índice não ajudaria em nada, pelo contrário, para o > delete, na tabela filha, ele causa um lock durante o tempo da DML > apenas, não durante a transação, em caso de se apagar um registro na > tabela mãe e esta propagar para a tabela filha. Se há um alto índice > de deletes na tabela mãe, causando assim talvez grandes tempos de > lock na tabela filha, não seria interessante criar um índice na fk? > > tomei como base, o que li no "Expert Oracle Database Architecture > Programming techniques and solutions" do Thomas Kyte, pag, 204. > > Desde já obrigado e um abraço. > > --- Em oracle_br@yahoogrupos.com.br , > "jlchiappa" <[EMAIL PROTECTED]> > escreveu > > > > Adriano, eu vi em outras mgs que o pessoal já te proveu os links com > > demonstrações, então vou falar só do conceito geral, que é ** muito > ** > > simples : veja vc, uma coluna FK significa que o valor dela deve ser > > chacedo contra uma outra tabela , e essa outra tabela TEM que ter > uma > > Pk ou UK presente, ok ? Muito bem, se tem PK ou UK, necessariamente > > tem índice lá na outra tabela, certo ? Se há índice, para cada > > registro na tabela-filha (que posui K) que vc inserir/alterar o > valor > > da coluna será pesquisado na tabela-pai, já que vc sabe que na pai > > necessariamente vc tem índice é natural que esse índice seja usado, > ok > > ? Não faz portanto o ** MENOR ** sentido vc indexar a coluna FK > nesse > > caso, o índice a ser usado é o que já existe na coluna PK/UK, a > > própria constraint PK/UK exige a presença de índice, sim ? > > Agora, imagine que vc vá fazer UPDATE/DELETE num registro da > > tabela-pai nessa coluna PK/UK : claro, se vc levar à ferro e fogo a > > teoria de bd relacional, ela sustenta que a chave *** nunca *** > > deveria mudar, se está mudando não é chave, mas suponha que vc > precise > > fazer isso - nesse caso, lógico, o valor alterado TEM QUE ser > > pesquisado na tabela-filha pra se checar se existe, aí sim se nõ > > houver índice na tabela-filha por essa coluna FK não tem jeito, a > > tabela terá que ser scaneada POR INTEIRO, e (claro) para evitar > > alterações enquanto isso, a tabela é lockada também... Então é isso, > > SE e APENAS SE vc o banco for ter que fazer pesquisa na coluna FK da > > tabela-filha devido à alteração de chave, aí SIM vc precisa de > índice > > na FK. E sim, vc estava 100% correto ao supor que cada índice (não > > importa aonde seja) adiciona overhead para DMLs (e em menor grau até > > pra DDLs, principalmente TRUNCATEs e quetais), então SIM, vc tem que > > pesar direitinho isso, e NUNCA, JAMAIS, sair simplesmente indexando > > alegremente tudo que é FK, ok ? Aqui no cliente atual o pessoal usou > > uma tool de modelagem que já sai criando automticamente índice pra > > TUDO que é FK, grande parte do meu trabalho de tuning aqui é > > simplesmente DROPAR essas coisas, EM ESPECIAL porque aqui é DW, a > > chave PK/Uk normalmente é sintética , é um NÚMERO "inventado" > > sequencial, normalmente não vejo razão ALGUMA de negócio pra essa > > chave ser alterada, então nenhum sentido em indexar FKs aqui. > > > > []s > > > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br , > "Adriano
Re: [oracle_br] Re: Criação de Índices em Chaves Estrangeiras
Foi exatamente o que o Chiappa disse... Se vc tem update na PK da tabela mae, ou delete em cascata na tabela mae, vc deve usar um indice na FK da tabela filha. Agora, outra duvida é quanto a joins... Se eu utilizar join em um select amarrando a tabela filha com a pai, eu não precisaria criar um indice na FK entao... até pq nesse caso a busca é inversa.. ou seja, a cada registro da tabela filha o BD vai procurar na tabela pai o registro correspondente àquela FK, e na tabela pai já existe índice por ser PK. Correto??? []'s Adriano - Original Message - From: rei_do_delphi To: oracle_br@yahoogrupos.com.br Sent: Thursday, January 31, 2008 7:39 AM Subject: [oracle_br] Re: Criação de Índices em Chaves Estrangeiras Chiappa, eu não entendi uma coisa só, supondo que esta tabela Mãe seja uma tabela com um alto índice de inserts e deletes, para o insert, um índice não ajudaria em nada, pelo contrário, para o delete, na tabela filha, ele causa um lock durante o tempo da DML apenas, não durante a transação, em caso de se apagar um registro na tabela mãe e esta propagar para a tabela filha. Se há um alto índice de deletes na tabela mãe, causando assim talvez grandes tempos de lock na tabela filha, não seria interessante criar um índice na fk? tomei como base, o que li no "Expert Oracle Database Architecture Programming techniques and solutions" do Thomas Kyte, pag, 204. Desde já obrigado e um abraço. --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > Adriano, eu vi em outras mgs que o pessoal já te proveu os links com > demonstrações, então vou falar só do conceito geral, que é ** muito ** > simples : veja vc, uma coluna FK significa que o valor dela deve ser > chacedo contra uma outra tabela , e essa outra tabela TEM que ter uma > Pk ou UK presente, ok ? Muito bem, se tem PK ou UK, necessariamente > tem índice lá na outra tabela, certo ? Se há índice, para cada > registro na tabela-filha (que posui K) que vc inserir/alterar o valor > da coluna será pesquisado na tabela-pai, já que vc sabe que na pai > necessariamente vc tem índice é natural que esse índice seja usado, ok > ? Não faz portanto o ** MENOR ** sentido vc indexar a coluna FK nesse > caso, o índice a ser usado é o que já existe na coluna PK/UK, a > própria constraint PK/UK exige a presença de índice, sim ? > Agora, imagine que vc vá fazer UPDATE/DELETE num registro da > tabela-pai nessa coluna PK/UK : claro, se vc levar à ferro e fogo a > teoria de bd relacional, ela sustenta que a chave *** nunca *** > deveria mudar, se está mudando não é chave, mas suponha que vc precise > fazer isso - nesse caso, lógico, o valor alterado TEM QUE ser > pesquisado na tabela-filha pra se checar se existe, aí sim se nõ > houver índice na tabela-filha por essa coluna FK não tem jeito, a > tabela terá que ser scaneada POR INTEIRO, e (claro) para evitar > alterações enquanto isso, a tabela é lockada também... Então é isso, > SE e APENAS SE vc o banco for ter que fazer pesquisa na coluna FK da > tabela-filha devido à alteração de chave, aí SIM vc precisa de índice > na FK. E sim, vc estava 100% correto ao supor que cada índice (não > importa aonde seja) adiciona overhead para DMLs (e em menor grau até > pra DDLs, principalmente TRUNCATEs e quetais), então SIM, vc tem que > pesar direitinho isso, e NUNCA, JAMAIS, sair simplesmente indexando > alegremente tudo que é FK, ok ? Aqui no cliente atual o pessoal usou > uma tool de modelagem que já sai criando automticamente índice pra > TUDO que é FK, grande parte do meu trabalho de tuning aqui é > simplesmente DROPAR essas coisas, EM ESPECIAL porque aqui é DW, a > chave PK/Uk normalmente é sintética , é um NÚMERO "inventado" > sequencial, normalmente não vejo razão ALGUMA de negócio pra essa > chave ser alterada, então nenhum sentido em indexar FKs aqui. > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "Adriano de Oliveira" > escreveu > > > > Pois é. > > Também li sobre os locks que podem acontecer em um delete cascade > por exemplo em uma tabela child > > onde a chave estrangeira não possui indice. > > Eu crio a estrutura do meu BD no ErWin, e ele cria por default os > indices pra todas as foreign keys. > > Mas eu tenho como escolher qual eu devo criar no banco propriamente > dito. > > Acredito que a gente deve analisar direito e decidir até que ponto > esse índice vai ajudar ou atrapalhar > > o sistema em si. > > Mas não sei a opinião de Certificados Oracle sobre isso.. > > > > []'s > > Adriano > > > > - Original
RES: [oracle_br] Re: Criação de Índices em Chaves Estrangeiras
Chiappa, Tudo bem em relação aos locks. Mas e quanto as consultas onde é necessário o join das tabelas PAIS com as tabelas FILHOS? Não acha que esta pode ser uma justificativa em relação a criação de índices nas foreign keys? Vejo como algo natural a necessidade de se fazer com certa frequência o join das tabelas PAIS com tabelas FILHOS, pelo menos num banco que não seja DW. Até mais. _ De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: quarta-feira, 30 de janeiro de 2008 08:08 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Criação de Índices em Chaves Estrangeiras Adriano, eu vi em outras mgs que o pessoal já te proveu os links com demonstrações, então vou falar só do conceito geral, que é ** muito ** simples : veja vc, uma coluna FK significa que o valor dela deve ser chacedo contra uma outra tabela , e essa outra tabela TEM que ter uma Pk ou UK presente, ok ? Muito bem, se tem PK ou UK, necessariamente tem índice lá na outra tabela, certo ? Se há índice, para cada registro na tabela-filha (que posui K) que vc inserir/alterar o valor da coluna será pesquisado na tabela-pai, já que vc sabe que na pai necessariamente vc tem índice é natural que esse índice seja usado, ok ? Não faz portanto o ** MENOR ** sentido vc indexar a coluna FK nesse caso, o índice a ser usado é o que já existe na coluna PK/UK, a própria constraint PK/UK exige a presença de índice, sim ? Agora, imagine que vc vá fazer UPDATE/DELETE num registro da tabela-pai nessa coluna PK/UK : claro, se vc levar à ferro e fogo a teoria de bd relacional, ela sustenta que a chave *** nunca *** deveria mudar, se está mudando não é chave, mas suponha que vc precise fazer isso - nesse caso, lógico, o valor alterado TEM QUE ser pesquisado na tabela-filha pra se checar se existe, aí sim se nõ houver índice na tabela-filha por essa coluna FK não tem jeito, a tabela terá que ser scaneada POR INTEIRO, e (claro) para evitar alterações enquanto isso, a tabela é lockada também... Então é isso, SE e APENAS SE vc o banco for ter que fazer pesquisa na coluna FK da tabela-filha devido à alteração de chave, aí SIM vc precisa de índice na FK. E sim, vc estava 100% correto ao supor que cada índice (não importa aonde seja) adiciona overhead para DMLs (e em menor grau até pra DDLs, principalmente TRUNCATEs e quetais), então SIM, vc tem que pesar direitinho isso, e NUNCA, JAMAIS, sair simplesmente indexando alegremente tudo que é FK, ok ? Aqui no cliente atual o pessoal usou uma tool de modelagem que já sai criando automticamente índice pra TUDO que é FK, grande parte do meu trabalho de tuning aqui é simplesmente DROPAR essas coisas, EM ESPECIAL porque aqui é DW, a chave PK/Uk normalmente é sintética , é um NÚMERO "inventado" sequencial, normalmente não vejo razão ALGUMA de negócio pra essa chave ser alterada, então nenhum sentido em indexar FKs aqui. []s Chiappa --- Em [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> os.com.br, "Adriano de Oliveira" <[EMAIL PROTECTED]> escreveu > > Pois é. > Também li sobre os locks que podem acontecer em um delete cascade por exemplo em uma tabela child > onde a chave estrangeira não possui indice. > Eu crio a estrutura do meu BD no ErWin, e ele cria por default os indices pra todas as foreign keys. > Mas eu tenho como escolher qual eu devo criar no banco propriamente dito. > Acredito que a gente deve analisar direito e decidir até que ponto esse índice vai ajudar ou atrapalhar > o sistema em si. > Mas não sei a opinião de Certificados Oracle sobre isso.. > > []'s > Adriano > > - Original Message - > From: Welvis Douglas > To: [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> os.com.br > Sent: Tuesday, January 29, 2008 2:48 PM > Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras > > > Então, aqui na empresa estou assumindo o lugar de outro dba.. ai quando fui fazer uma manuteção com a supervisão dele.. estava para criar uma indice para FK, ai perguntei para ele... e ele disse que isso tbm não precisa mais... > > bom resumindo, 4 pessoas que conheço DBA's falaram que é mito, porem aqui onde eu trabalho eles tem essa cultura... > > sacou, > > eu tenho tabela aqui com mais de 20GB, um indice desse deve ser bem grandinho.. né... > > poderia diminurir um certo espaço.. , mas como é um problema cultural... > > fazer o que.. kk > > abraço > > - Original Message - > From: Andre Santos > To: [EMAIL PROTECTED] <mailto:oracle_br%40yahoogrupos.com.br> os.com.br > Sent: Tuesday, January 29, 2008 3:18 PM > Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras > > Welvis > > Será que é mito mesmo? > Já li algumas coisas referentes a "lock" para verificação de integridade > referencial, que seria melhor
[oracle_br] Re: Criação de Índices em Chaves Estrangeiras
Chiappa, eu não entendi uma coisa só, supondo que esta tabela Mãe seja uma tabela com um alto índice de inserts e deletes, para o insert, um índice não ajudaria em nada, pelo contrário, para o delete, na tabela filha, ele causa um lock durante o tempo da DML apenas, não durante a transação, em caso de se apagar um registro na tabela mãe e esta propagar para a tabela filha. Se há um alto índice de deletes na tabela mãe, causando assim talvez grandes tempos de lock na tabela filha, não seria interessante criar um índice na fk? tomei como base, o que li no "Expert Oracle Database Architecture Programming techniques and solutions" do Thomas Kyte, pag, 204. Desde já obrigado e um abraço. --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > Adriano, eu vi em outras mgs que o pessoal já te proveu os links com > demonstrações, então vou falar só do conceito geral, que é ** muito ** > simples : veja vc, uma coluna FK significa que o valor dela deve ser > chacedo contra uma outra tabela , e essa outra tabela TEM que ter uma > Pk ou UK presente, ok ? Muito bem, se tem PK ou UK, necessariamente > tem índice lá na outra tabela, certo ? Se há índice, para cada > registro na tabela-filha (que posui K) que vc inserir/alterar o valor > da coluna será pesquisado na tabela-pai, já que vc sabe que na pai > necessariamente vc tem índice é natural que esse índice seja usado, ok > ? Não faz portanto o ** MENOR ** sentido vc indexar a coluna FK nesse > caso, o índice a ser usado é o que já existe na coluna PK/UK, a > própria constraint PK/UK exige a presença de índice, sim ? > Agora, imagine que vc vá fazer UPDATE/DELETE num registro da > tabela-pai nessa coluna PK/UK : claro, se vc levar à ferro e fogo a > teoria de bd relacional, ela sustenta que a chave *** nunca *** > deveria mudar, se está mudando não é chave, mas suponha que vc precise > fazer isso - nesse caso, lógico, o valor alterado TEM QUE ser > pesquisado na tabela-filha pra se checar se existe, aí sim se nõ > houver índice na tabela-filha por essa coluna FK não tem jeito, a > tabela terá que ser scaneada POR INTEIRO, e (claro) para evitar > alterações enquanto isso, a tabela é lockada também... Então é isso, > SE e APENAS SE vc o banco for ter que fazer pesquisa na coluna FK da > tabela-filha devido à alteração de chave, aí SIM vc precisa de índice > na FK. E sim, vc estava 100% correto ao supor que cada índice (não > importa aonde seja) adiciona overhead para DMLs (e em menor grau até > pra DDLs, principalmente TRUNCATEs e quetais), então SIM, vc tem que > pesar direitinho isso, e NUNCA, JAMAIS, sair simplesmente indexando > alegremente tudo que é FK, ok ? Aqui no cliente atual o pessoal usou > uma tool de modelagem que já sai criando automticamente índice pra > TUDO que é FK, grande parte do meu trabalho de tuning aqui é > simplesmente DROPAR essas coisas, EM ESPECIAL porque aqui é DW, a > chave PK/Uk normalmente é sintética , é um NÚMERO "inventado" > sequencial, normalmente não vejo razão ALGUMA de negócio pra essa > chave ser alterada, então nenhum sentido em indexar FKs aqui. > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "Adriano de Oliveira" > escreveu > > > > Pois é. > > Também li sobre os locks que podem acontecer em um delete cascade > por exemplo em uma tabela child > > onde a chave estrangeira não possui indice. > > Eu crio a estrutura do meu BD no ErWin, e ele cria por default os > indices pra todas as foreign keys. > > Mas eu tenho como escolher qual eu devo criar no banco propriamente > dito. > > Acredito que a gente deve analisar direito e decidir até que ponto > esse índice vai ajudar ou atrapalhar > > o sistema em si. > > Mas não sei a opinião de Certificados Oracle sobre isso.. > > > > []'s > > Adriano > > > > - Original Message - > > From: Welvis Douglas > > To: oracle_br@yahoogrupos.com.br > > Sent: Tuesday, January 29, 2008 2:48 PM > > Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras > > > > > > Então, aqui na empresa estou assumindo o lugar de outro dba.. ai > quando fui fazer uma manuteção com a supervisão dele.. estava para > criar uma indice para FK, ai perguntei para ele... e ele disse que > isso tbm não precisa mais... > > > > bom resumindo, 4 pessoas que conheço DBA's falaram que é mito, > porem aqui onde eu trabalho eles tem essa cultura... > > > > sacou, > > > > eu tenho tabela aqui com mais de 20GB, um indice desse deve ser > bem grandinho.. né... > > > > poderia diminurir um certo espaço.. , mas como é um problema > cultural... > > > > fazer o que.. kk > > > > abraço > > > > - Original Message - > > From: Andre Santos > > To: oracle_br@yahoogrupos.com.br > > Sent: Tuesday, January 29, 2008 3:18 PM > > Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras > > > > Welvis > > > > Será que é mito mesmo? > > Já li algumas coisas referentes a "lock" para verificaçã
[oracle_br] Re: Criação de Índices em Chaves Estrangeiras
Adriano, eu vi em outras mgs que o pessoal já te proveu os links com demonstrações, então vou falar só do conceito geral, que é ** muito ** simples : veja vc, uma coluna FK significa que o valor dela deve ser chacedo contra uma outra tabela , e essa outra tabela TEM que ter uma Pk ou UK presente, ok ? Muito bem, se tem PK ou UK, necessariamente tem índice lá na outra tabela, certo ? Se há índice, para cada registro na tabela-filha (que posui K) que vc inserir/alterar o valor da coluna será pesquisado na tabela-pai, já que vc sabe que na pai necessariamente vc tem índice é natural que esse índice seja usado, ok ? Não faz portanto o ** MENOR ** sentido vc indexar a coluna FK nesse caso, o índice a ser usado é o que já existe na coluna PK/UK, a própria constraint PK/UK exige a presença de índice, sim ? Agora, imagine que vc vá fazer UPDATE/DELETE num registro da tabela-pai nessa coluna PK/UK : claro, se vc levar à ferro e fogo a teoria de bd relacional, ela sustenta que a chave *** nunca *** deveria mudar, se está mudando não é chave, mas suponha que vc precise fazer isso - nesse caso, lógico, o valor alterado TEM QUE ser pesquisado na tabela-filha pra se checar se existe, aí sim se nõ houver índice na tabela-filha por essa coluna FK não tem jeito, a tabela terá que ser scaneada POR INTEIRO, e (claro) para evitar alterações enquanto isso, a tabela é lockada também... Então é isso, SE e APENAS SE vc o banco for ter que fazer pesquisa na coluna FK da tabela-filha devido à alteração de chave, aí SIM vc precisa de índice na FK. E sim, vc estava 100% correto ao supor que cada índice (não importa aonde seja) adiciona overhead para DMLs (e em menor grau até pra DDLs, principalmente TRUNCATEs e quetais), então SIM, vc tem que pesar direitinho isso, e NUNCA, JAMAIS, sair simplesmente indexando alegremente tudo que é FK, ok ? Aqui no cliente atual o pessoal usou uma tool de modelagem que já sai criando automticamente índice pra TUDO que é FK, grande parte do meu trabalho de tuning aqui é simplesmente DROPAR essas coisas, EM ESPECIAL porque aqui é DW, a chave PK/Uk normalmente é sintética , é um NÚMERO "inventado" sequencial, normalmente não vejo razão ALGUMA de negócio pra essa chave ser alterada, então nenhum sentido em indexar FKs aqui. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Adriano de Oliveira" <[EMAIL PROTECTED]> escreveu > > Pois é. > Também li sobre os locks que podem acontecer em um delete cascade por exemplo em uma tabela child > onde a chave estrangeira não possui indice. > Eu crio a estrutura do meu BD no ErWin, e ele cria por default os indices pra todas as foreign keys. > Mas eu tenho como escolher qual eu devo criar no banco propriamente dito. > Acredito que a gente deve analisar direito e decidir até que ponto esse índice vai ajudar ou atrapalhar > o sistema em si. > Mas não sei a opinião de Certificados Oracle sobre isso.. > > []'s > Adriano > > - Original Message - > From: Welvis Douglas > To: oracle_br@yahoogrupos.com.br > Sent: Tuesday, January 29, 2008 2:48 PM > Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras > > > Então, aqui na empresa estou assumindo o lugar de outro dba.. ai quando fui fazer uma manuteção com a supervisão dele.. estava para criar uma indice para FK, ai perguntei para ele... e ele disse que isso tbm não precisa mais... > > bom resumindo, 4 pessoas que conheço DBA's falaram que é mito, porem aqui onde eu trabalho eles tem essa cultura... > > sacou, > > eu tenho tabela aqui com mais de 20GB, um indice desse deve ser bem grandinho.. né... > > poderia diminurir um certo espaço.. , mas como é um problema cultural... > > fazer o que.. kk > > abraço > > - Original Message - > From: Andre Santos > To: oracle_br@yahoogrupos.com.br > Sent: Tuesday, January 29, 2008 3:18 PM > Subject: Re: [oracle_br] Criação de Índices em Chaves Estrangeiras > > Welvis > > Será que é mito mesmo? > Já li algumas coisas referentes a "lock" para verificação de integridade > referencial, que seria melhor caso houvesse um índice na FK. > > Precisaríamos verificar... vou tentar pesquisar algo a respeito. > > De qualquer forma, o que o Adriano mencionou sobre o maior custo num INSERT > com 10 índices é verdade. > Pessoalmente, acho que é melhor analisar os casos em que seria melhor ter um > índice (e não criá-los indiscriminadamente para todas as FK's). > > [ ]'s > > André > > Em 29/01/08, Welvis Douglas <[EMAIL PROTECTED]> escreveu: > > > > Meu amigo, quando eu fiz o curso do 10g em 2005, a pessoa que deu o > > curso disse que esse era um mido to oracle 8. > > > > ... > > > > att, > > > > Welvis Douglas > > > > - Original Message - > > From: Adriano de Oliveira > > To: oracle_br@yahoogrupos.com.br > > Sent: Tuesday, January 29, 2008 11:05 AM > > Subject: [oracle_br] Criação de Índices em Chaves Estrangeiras > > > > Olá pessoal, bom dia. >
