Ribamar Sousa escreveu: > Se eu permitir que um campo que é a chave estrangeira seja nulo estou > quabrando a integridade, pois em sendo nulo o relacionamento já é > permitido (quando somente deveria ser permitido se o campo da FK fosse > igual ao da PK da outra). > Você não está quebrando a integridade porque a informação pode ser desconhecida; por outro lado, se a informação for conhecida, ela tem que estar de acordo com a tabela referenciada. No exemplo abaixo, eu posso dizer que pessoas.cidade é um campo opcional e uma chave estrangeira para cidades.nome. Assim, posso permitir que a informação pessoas.cidade seja omitida, entretanto, caso ela seja informada eu tenho que garantir que a mesma esteja disponível em cidades.nome.
pessoas (nome, cidade) cidades (nome, estado) > Em um campo de telefone, se eu aceitar nulo eu poderei tem telefones > duplicados. Uma saída para isso eu adotei o índice parcial (no exemplo > que divulguei do banco pessoa). > Ugh? Veja bem, NULL é "diferente" de NULL (na verdade, é uma expressão desconhecida, ou seja, NULL). Partindo dessa premissa, duas tuplas contendo NULL não estão duplicadas. > Acho que o nulo é tão escorregadio que se de fato decidirmos adotá-lo, > que nos cerquemos de cuidados para não deixá-lo escapar. > É como o Diogo e o Osvalda disseram: você tem que saber de que o NULL é capaz (começando pela lógica dos três valores [1] :-) para poder utilizar campos com essa propriedade. [1] http://pt.wikipedia.org/wiki/L%C3%B3gica_tern%C3%A1ria -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
