Em 07/10/2008, às 05:42, Yoshio escreveu:
2008/10/7 Magno Junior <[EMAIL PROTECTED]>:
> Não entendi.
> Eu poderia ter uma tabela chamada categoria, com apenas um campo
> chamado categoria, sendo esse unico campo a propria chave primaria
da
> tabela, é isso?
Isso
> Não ficaria mais complicado para fazer uma consulta?
Não sei. Esse é um dos meus dilemas. Voltando a tabela de produtos,
o select dela não precisaria de um join na tabela de categorias:
SELECT * from produtos;
| código | nome | categoria |
---------------------------------------------------------------
| 1 | arroz | grãos |
| 2 | feijão | grãos |
| 3 | maça | frutas |
O select exibe as categorias sem precisar de uma view ou join.
É verdade, enquanto o atributo categoria não tiver nenhuma
dependência, é mais prático usá-lo como um campo ao invés de usar uma
FK.
No entanto, vejo dois problemas ao modelar um campo desse tipo como
varchar sem nenhuma restrição:
1. Pode gerar inconsistências dentro das categorias (nomes diferentes
para a mesma categoria).
2. Listar todas as categorias existentes sem ter uma tabela separada
pode ser muito caro se a tabela de produtos for grande.
Logo podemos resolver o dilema de duas formas:
1. Se as categorias não precisam ser modificadas pelo usuário (mudam
raramente ao longo do tempo), podemos criar um campo ENUM ou um
domínio com uma check constraint para os nomes de categorias válidos.
2. Se as categorias podem sofrer manutenção pelo usuário recomendo o
uso de chave estrangeira, pois quando você for apresentar uma lista de
opções para o usuário, poderá fazer um select na tabela de categorias
ao invés de um SELECT DISTINCT na tabela produtos.
--
Diogo Biazus
[EMAIL PROTECTED]
http://www.softa.com.br
http://www.postgresql.org.br
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
