2010/1/7 Mozart Hasse <[email protected]>: >> 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
Eu também. Veja que o artigo não identifica a chave primária com uma eventual chave artificial. E inclui a proposta de que o valor não deve ser manipulável, talvez nem visível, para usuários e aplicações. Ou seja, não entendi qual meu espantalho, nem o que há de errado na minha frase supracitada. > Usando a definição mais "moderna" da "minoria" que ouviu falar do Wieringa e > De Jonge (última moda, 1991) Que, segundo o artigo da Wikipedia supracitado, não deveria sequer aparecer para o usuário. >> 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. Em alguns casos… ou seja, seu uso só se justifica nas exceções. > Recomendo que poste suas lamentações sobre os > "abusos" que só você sabe e viu onde aconteceram na lista pertinente Ah… acho que você não deve estar trabalhando com os sistemas que se têm feito só com chaves artificiais, por causa de ORMs e coisas tais. Se tiveres pachorra, pesquisa sobre Ruby on Rails, Hibernate et alli. >> > 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 Que é irrelavante. > e no número de árvores Que não é afetado. > que o otimizador precisa analisar para escolher o plano de execução. Que será escolhido apenas uma vez para cada consulta, portanto não é relevante para a grande maioria dos sistemas. >> 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. Essa junção existe, mas é minoria. Otimização precoce é a raiz de toda sorte de males. > 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. Precisamente minha experiência. E nesses projetos, só uma minoria das tabelas precisa de chaves artificiais. A maioria vai melhor com chaves naturais, inclusive aquelas que incluem chaves artificiais herdadas de tabelas-mãe. > 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. Desde quando estou falando mal de chaves artificiais? Estou dizendo que são abusadas, e como. >> 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). Por acaso sou especialista na área, e perguntar ao Tom não vai torná-los mais consistentes. Isso é consenso, entre quem repara nessas coisas. > Só falta saber identificar quando ocorre o abuso, justificar por quê te > parece um abuso e citá-lo no momento e local apropriados. O que tentei fazer, mas pelo jeito não falo a mesma língua que tu. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:[email protected] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[email protected] Sent from Sao Paulo, SP, Brésil _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
