Realmente gosto disto que está ocorrendo aqui. Faz valer o nome deste lugar: "Lista de discussão". Segue a minha contribuição:
Simplesmente não gosto do estado NULL para o valor de um atributo de uma Relação. Usar ou permitir valores nulos para um atributo é uma péssima idéia e pode causar grandes problemas. Podemos ignorar completamente este estado e definir para cada atributo um valor padrão. O uso das "chaves artificiais" cresceu muito com a adoção de Frameworks e seus ORMs. Inegavelmente o uso destas ferramentas simplificam o desenvolvimento de sistemas mas afastam os desenvolvedores das teorias que fundaram o SGBD que hoje utilizamos. Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de chaves naturais compostas. Alias, ORM não são muito legais. Até o David disse: "Stop trying to generate SQL." [1]. Acredito na importância de se estudar os trabalhos dos conhecidos pesquisadores neste assunto (e que até possuem idéias diferentes) como Date e Celko. Não que as idéias destes devessem ser aplicada à risca, pois, cada caso é um caso. É importante conhecer as ferramentas que temos a disposição e as diferentes maneiras com as quais podemos solucionar um problema. Podemos fixar um prego na parede com uma chave de fenda apesar de ser muito mais simples com um martelo. E tendo um martelo é possível usar o cabo ou a cabeça... É o uso da ferramenta, mais a técnica usada de forma apropriada que faz a diferença e torna o trabalho mais simples e bem feito. Se focarmos nas teorias, usaríamos mais as chaves naturais que podemos encontrar em uma Relação. Mas existem situações em que precisamos usar as chaves artificiais. Quando nossa regra de negócio permite inserir um registro antes mesmo de se ter a chave natural completa. Por exemplo: No caso da locadora de vídeos. Se for possível reservar um filme sem necessariamente especificar para quem, ou seja, apenas queremos indicar que um filme está reservado para "alguém", a chave natural não estaria completa pois a chave natural da Relação "Reserva" inclui uma referência para o cliente que quer o filme e que neste caso não está preenchida. Pode aqui estar um exemplo de uso do NULL, onde o código do cliente é indefinido. Mas como escrevi logo acima, podemos esquecer dos valores nulos e usar valores defaults o que na minha opinião é a melhor alternativa. Então, neste exemplo, a Relação "Reserva" precisaria ter uma chave artificial identificando uma reserva sem mesmo ter a informação do cliente que reservou o filme. Apesar de existir algumas vantagens no uso das chaves naturais como por exemplo a não necessidade de se criar uma nova coluna para uma outra chave ou a melhor representação de acordo com o Domínio, na prática, uso muito as chaves artificiais e as chaves candidatas naturais se tornam únicas e não nulas. Tornando as chaves naturais unicas e não nulas, elimina-se o problema da duplicidade que pode ocorrer usando chaves artificiais sem tratar as naturais como no exemplo: cd_pessoa | nome --------------------------- 1 | João 2 | João Chaves artificiais simplificam as queries ad hoc quando é preciso fazer os joins e torna possível o uso dos ORMs. Um exemplo de Relação usando uma chave artificial e tratando a natural: CREATE TABLE pessoas ( cd_pessoa serial PRIMARY KEY, nome CHARACTER VARYING NOT NULL DEFAULT 'não especificado', cpf CHARACTER VARYING NOT NULL UNIQUE ); Quando criamos uma restrição de unicidade, automaticamente criamos um índice para a propriedade da relação. Isso acontece porque no momento da inserção de uma nova tupla, o SGBD pesquisa por uma ocorrência do valor que se quer inserir na Relação. Caso não encontrado, o valor é inserido. O índice ajuda nesta pesquisa. Este comportamento é ótimo pois normalmente, também usamos esta propriedade para fazer as buscas de dentro do nosso sistema. Referências: http://books.google.com.br/books?id=y_eVBB5qdwMC&printsec=frontcover#v=onepage&q=&f=false http://en.wikipedia.org/wiki/Natural_key [1] http://people.planetpostgresql.org/dfetter/index.php?/archives/40-Removing-Much-of-the-Suck-from-ORMs.html -- Tarcisio F. Sassara _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
