Leandro, > Para a minoria (geralmente) dos casos em que é necessária, em SQL, uma > chave artificial (e explicitada ao usuário), ela pode tranqüilamente > ser a primária, não faz a menor diferença que a natural seja declarada > sem ser primária.
E ainda diz que sou em que crio espantalhos. Estou falando disso aqui: http://en.wikipedia.org/wiki/Surrogate_key Usando a definição mais "moderna" da "minoria" que ouviu falar do Wieringa e De Jonge (última moda, 1991) > Como não tem, se uma chave artificial é um atributo a mais? E se é > freqüentemente abusado? Já expliquei por que esse atributo a mais melhora o desempenho e a estrutura da aplicação, consulte o histórico. Recomendo que poste suas lamentações sobre os "abusos" que só você sabe e viu onde aconteceram na lista pertinente, que até onde eu saiba não é esta. > > 2. Tamanho do comando SQL em consultas com várias junções, facilitando a > > vida do compilador e do otimizador; > Irrelevante? tokenizado. Relevante, pois influi no número de tokens e no número de árvores que o otimizador precisa analisar para escolher o plano de execução. > > 3. Melhor estimativa de quantos registros cada condição irá retornar, > > melhorando o desempenho. > Estou para ver alguma diferença prática. Muito me surpreenderia se > houvesse alguma nas tabelas menores, que são a maioria. Pode ser uma senhora diferença quando juntar tabelas menores (menos de 10000 registros) com tabelas maiores e o otimizador decidir usar o índice ao invés de percorrer todos os registros da pequena tabela filha. No meu planeta a gente precisa disso com frequência. Siga meu conselho e experimente, especialmente num projeto com volume de dados em que desempenho seja um dos requisitos e o hardware não seja ilimitado para esconder más decisões de modelagem. > > Novamente: se o seu problema é má documentação, critique o mau hábito, > > não as chaves artificias, que não tem nada a ver com isso. > Na verdade, a questão aí nem é documentação em si? é o próprio SQL que > não suporta a divisão entre conceitual e físico, e o ferramental em > torno não ajuda tanto quanto deveria. Novamente: se o seu problema é o ferramental que não ajuda a documentar, critique-o na lista apropriada. Poupe as chaves artificias, que não tem nada a ver com isso. > > Não podemos esquecer que os sistemas servem para resolver *problemas*, não > > para gerar diagramas conceitualmente "perfeitos". > E qual problema exige os nomes inconsistentes dos atributos nas > relações do dicionário de dados do Oracle? Se eles te parecem inconsistentes, consulte os especialistas da área (ORACLE) na lista pertinente ou pergunte pro Tom (asktom.oracle.com). > Claro que tem! A má modelagem se traduz no abuso das chaves artificiais. Só falta saber identificar quando ocorre o abuso, justificar por quê te parece um abuso e citá-lo no momento e local apropriados. > Pelo contrário, a exceção é precisar de chave artificial. (...) > Só a minha experiência, e a de muitos colegas. (...) > Coloca, mas equivocadamente. Não faz sequer um teste > para verificar se as regrinhas que aprendeu de ouvido se aplicam a seu > caso. (...) > A opção existir não significa que se aplica tão geralmente. (...) > Relevante, sim, mas em que casos? (...) > o uso de níveis de > isolamento inferior ao serializável dá um ganho geralmente > insignificante, mas gera perdas significativas ... (...) > Isso seria meio absurdo. Como 70% das tabelas terão filhas de > tamanhos significativos, e maiores que o de suas mães? (...) > Altere, mas não estrague o resto do modelo. (depois de muitas caras de espanto com cada trecho) Depende da aplicação. Pelo visto nos últimos 15 anos vivemos em mundos distintos, com colegas distintos e requisitos mais distintos ainda. Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
