Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Ribamar Sousa]

2008/8/14 Euler Taveira de Oliveira <[EMAIL PROTECTED]>

> 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.


Me referi ao fato de em se permitindo nulo, veja o que ocorre:

clientesprodutos

codigo(pk)codigo (pk)
nomecod_pessoa()fk

No exemplo acima, posso cadastrar um produto sem indicar o cliente, pois a
FK permite nulo.

>
> > 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.
>

Tens razão. Todos os NULOS são nulos e aparentemente duplicados, mas como
NULL é diferente de NULL, não estão duplicados.

Mas a que eu quiz me referir com a idéia foi que isso é algo indesejável e
que sugestão contornava isso.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Euler Taveira de Oliveira]

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

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Ribamar Sousa]

2008/8/13 Shander Lyrio <[EMAIL PROTECTED]>

>
> Ribamar Sousa wrote:
> >
> > Acredito que usando NULL alivia mais a carga do DBA que a do SGBD. :)
>
> Este é o ponto, por isso sou menos rigoroso com relação a eles,
> haja
> visto que também sou programador e não apenas DBA.
>
> > 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.
>
>Aí é que está o problema, espero que não seja só eu que tenha prazos
> super apertados para entregar sistemas.


Bem, acredito que quando temos nossas justificativas que se justificam
estamos perdoados.
Apenas estou mexendo nisso por achar que "sempre" devemos optar pela melhor
(mais profissional)  saída, exceto quando o chefe nos pede outra (fiz muitas
dessas), o prazo, etc.


>
> --
> Shander Lyrio
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Shander Lyrio]

Ribamar Sousa wrote:
> 
> Acredito que usando NULL alivia mais a carga do DBA que a do SGBD. :)

Este é o ponto, por isso sou menos rigoroso com relação a eles, haja 
visto que também sou programador e não apenas DBA.

> 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.

Aí é que está o problema, espero que não seja só eu que tenha prazos 
super apertados para entregar sistemas.

--
Shander Lyrio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Ribamar Sousa]

2008/8/13 Evandro Ricardo Silvestre <[EMAIL PROTECTED]>

>
>
> Ribamar Sousa wrote:
> >
> > 2008/8/13 Alisson Viegas | Acsiv Sistemas <[EMAIL PROTECTED]
> > >
> >
> > Ribamar, to migrando pra SGDB (sempre usei DBF).
> >
> > Poderiam me explicar por quê correr dos nulos.
> >
> > Sempre pensei que nulos "aliviava" a carga do banco.
> >
> > Acredito que usando NULL alivia mais a carga do DBA que a do SGBD. :)
> >
> > Bem, o que tenho aprendido em minhas leituras de livros de teoria de
> > bancos de dados e ainda bem pouco em minha experiência, é que os nulos
> > são geralmente problemáticos e geram comportamentos inesperados em
> > muitas situações.
> >
> > 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).
> Mas quando deseja ter um relacionamento 0-1 não é necessário ter a FK
> como NULL? Como vc faz esse tipo de relacionamento?
>

Nunca fiz mas logicamente se faz permitindo nulo.
Me referia aos relacionamentos mais comuns que são 1 para N ou o contrário.

___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Evandro Ricardo Silvestre]

Ribamar Sousa wrote:
>
> 2008/8/13 Alisson Viegas | Acsiv Sistemas <[EMAIL PROTECTED] 
> >
>
> Ribamar, to migrando pra SGDB (sempre usei DBF).
>
> Poderiam me explicar por quê correr dos nulos.
>
> Sempre pensei que nulos "aliviava" a carga do banco.
>
> Acredito que usando NULL alivia mais a carga do DBA que a do SGBD. :)
>
> Bem, o que tenho aprendido em minhas leituras de livros de teoria de 
> bancos de dados e ainda bem pouco em minha experiência, é que os nulos 
> são geralmente problemáticos e geram comportamentos inesperados em 
> muitas situações.
>
> 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).
Mas quando deseja ter um relacionamento 0-1 não é necessário ter a FK 
como NULL? Como vc faz esse tipo de relacionamento?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Ribamar Sousa]

2008/8/13 Alisson Viegas | Acsiv Sistemas <[EMAIL PROTECTED]>

>  Ribamar, to migrando pra SGDB (sempre usei DBF).
>
> Poderiam me explicar por quê correr dos nulos.
>
> Sempre pensei que nulos "aliviava" a carga do banco.
>
> Acredito que usando NULL alivia mais a carga do DBA que a do SGBD. :)

Bem, o que tenho aprendido em minhas leituras de livros de teoria de bancos
de dados e ainda bem pouco em minha experiência, é que os nulos são
geralmente problemáticos e geram comportamentos inesperados em muitas
situações.

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).

Quando vou fazer operações o nulo tem suas regras próprias que dificultam
muito e acaba retornando o que não é esperado, se eu não observar com
carinho.

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).

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.

Não precisamos ser puristas ou coisa que o valha pois tudo tem seu preço,
mas acredito que sempre devemos perseguir o profissionalismo, com as
melhores soluções.

-- 
Ribamar FS - [EMAIL PROTECTED]
http://ribafs.net
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Hubert Lubaczewski: NULLs vs. NOT IN()

[Osvaldo Rosario Kussama]

Alisson Viegas | Acsiv Sistemas escreveu:
> Ribamar, to migrando pra SGDB (sempre usei DBF).
> 
> Poderiam me explicar por quê correr dos nulos.
> 
> Sempre pensei que nulos “aliviava” a carga do banco.
> 
>  
> 
>  
> 
> At.te,
> Alisson Viegas
> [EMAIL PROTECTED]
> 
> ---
> Acsiv Sistemas
> www.acsiv.com.br 
> 
>  
> 
>  
> 
> *De:* [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] *Em nome de 
> *Ribamar Sousa
> *Enviada em:* quarta-feira, 13 de agosto de 2008 12:12
> *Para:* Comunidade PostgreSQL Brasileira
> *Assunto:* Re: [pgbr-geral] Hubert Lubaczewski: NULLs vs. NOT IN()
> 
>  
> 
> 2008/8/13 Osvaldo Kussama <[EMAIL PROTECTED] 
> >
> 
> Ribamar:
> 
> Talvez seja o caso descrito no manual:
> 
> http://www.postgresql.org/docs/current/interactive/functions-subquery.html#AEN15302
> 
> "Note that if the left-hand expression yields null, or if there are no
> equal right-hand values and at least one right-hand row yields null,
> the result of the NOT IN construct will be null, not true. This is in
> accordance with SQL's normal rules for Boolean combinations of null
> values."
> 
> A combinação de NULL com NOT IN nem sempre dá o resultado que
> usualmente (bom senso?) esperamos.
> 
> Osvaldo
> 
> 
> Osvaldo, parece que isso reforça a grande recomendação dos gurus e mestre:
> 
> "Corram dos nulos!".
> 
> Mas e se o bichim correr atraz da gente? :)
> 


A idéia de NULL é algo que normalmente confunde os iniciantes em banco 
de dados.

Usualmente NULL significa algo desconhecido, algo que não tem valor.

NULL não é uma string vazia '' (uma string vazia é algo conhecido: é 
uma string de comprimento zero).

Outra grande confusão: NULL = NULL? ou NULL <> NULL?
Como NULL é algo desconhecido como posso saber se: "algo que não sei o 
que é" pode ser igual (ou diferente) de "algo que não tenho a menor 
idéia do que seja"? Por isso a resposta para qualquer destas duas 
comparações é NULL! (isto é: não sei).

E se comparar algum valor com NULL? Por ex. 10 = NULL ou 10 <> NULL? 
Também em ambos os casos o resultado é NULL.

Como saber se uma expressão é ou não NULL?
Utilize: IS [ NOT ] NULL
Assim: 10 IS NULL dá como resposta falso.

Como fazer para considerar como igual ou diferente o resultado de 
comparações envolvendo NULL?
Utilize: IS [ NOT ] DISTINCT FROM
Assim: 10 IS DISTINCT FROM NULL dá como resposta verdadeiro;
NULL IS DISTINCT FROM NULL dá como resposta falso.

E tenha muito cuidado com a utilização de IN e NOT IN.

SELECT 10 IN (10,20); ==> verdadeiro
SELECT 10 NOT IN (10,20); ==> falso
SELECT 10 IN (NULL,10,20); ==> verdadeiro
SELECT 10 NOT IN (NULL,10,20); ==> false

SELECT 30 IN (10,20); ==> falso
SELECT 30 NOT IN (10,20); ==> verdadeiro
SELECT 30 IN (NULL,10,20); ==> NULL
SELECT 30 NOT IN (NULL,10,20); ==> NULL

Se a expressão do lado esquerdo do IN (ou NOT IN) for NULL o resultado 
será sempre NULL.

Por isso sempre tome cuidado ao utilizar NULL.

Ele pode ser útil?
Sim, por ex. uma data de encerramento contendo NULL normalmente 
significa que o item ainda está ativo. É só tomar os devidos cuidados 
ao utilizá-lo.

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral