Bom dia a Todos! Apesar de ter fugido da minha dúvida inicial que era somente como "USAR" campos padrões no Postgres acabou se tornando uma "Discussão" muito produtiva a respeito de conceitos e idéias de diferentes partes. Agradeço à todos que responderam, e opinaram a respeito e também informo que já estou utilizando tais campos em minhas aplicação e até agora (em homologação) está funcionando conforme o esperado.
Atenciosamente, Eder Sousa On Fri, 1 Jan 2010 16:27:56 -0200, Tarcísio Sassara <[email protected]> wrote: > 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: > <script type="text/javascript" src="http://www.softpira.com/homemail/program/js/tiny_mce/themes/advanced/langs/pt.js";></script>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 _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
