Acho que ele também está preocupada com índices extras também, mas na verdade os índices da chave extrangeiras geralmente ajudam:
Desculpem aqueles que não compreendem inglês: *http://www.devx.com/gethelpon/10MinuteSolution/16595/0/page/2* ** *Reasons for Foreign Key Constraints *There are many reasons for creating an index that supports the foreign key (FK) constraint. The first and the most obvious one is that the FK constraint represents a relation between tables, and if these tables are part of a SQL query, there's a 99.9 percent chance that they will be joined on the constraint column. In this case you definitely need an index that supports SQL queries. Another reason to have indexes for FK constraints is to avoid locking conflicts during an update of the child table. Oracle provides a row-level locking mechanism that removes many locking problems contained in databases with page-level and block-level locking. However, even row-level locking won't help if frequent updates to the child table cause it to lock the entire parent table just because the supporting index is missing. There is also a less-obvious problem that occurs with massive DELETE operations on the parent table. This is dangerous because, unlike the SELECT command, it triggers SQL queries implicitly in the background and you could spend hours and days trying to figure out why your simple DELETE command is unable to complete. -Evandro 2010/4/20 Osvaldo Kussama <osvaldo.kuss...@gmail.com> > Em 20 de abril de 2010 17:35, Humberto Reis > <humbe...@neotecnologia.net> escreveu: > > Caros colegas, > > O que consome menos recuso do banco (leia-se desempenho) usar integridade > > referencial com chave estrangeira ou controlar isso nos gatilhos de cada > > tabela? > > > Sem entrar no mérito do aspecto de "reinvenção da roda" creio que é > muito difícil desenvolver gatilhos tão eficientes quanto os mecanismos > de integridade referencial do PostgreSQL. > Talvez essa alternativa se aplica a outro SGBD. > > Osvaldo > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
