Salvar valor vazio em campo do tipo int

[André da Silva Severino]

Bom dia pessoal, como vocês lidam com a situação de salvar valores nulos(vazios) em campos do tipo inteiro ? E ainda por cima FK.

Vocês criam um registro do tipo (Não definido) e depois faz uma verificação se for vazio insere esse valor por default ?

Incorrect integer value: '' for column 'fk_id_clienteEstilo' at row 1

Obrigado e até mais

--
Att,

André da Silva Severino

Desenvolvedor web

(19) 8847.3747

Email: andredasil...@gmail.com

Url: http://andrewd.com.br

[Cassiano Ricardo Mourão]

Cara se eu não me engano... vazio != NULL. No caso: inteiro PODE ter valor null, mas não pode ter vazio.

Vazio se aplica à string...

Enfim, insere NULL que vai.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "php-brasil" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para php-b...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para php-brasil+...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/php-brasil?hl=pt-BR.

[André da Silva Severino]

Olá Cassiano, geralmente eu faço desta forma:

$campo = ( $_POST['valor'] != '' ) ? $_POST['valor'] : NULL;

acho que é assim mesmo então né? achei que tinha alguma config sei lá pra deixar + 'bonito' o código kkkk.

obrigado

[Cassiano Ricardo Mourão]

Qnd vc envia só o $_POST['valor'] e ele tá vazio ( '' ) ele dá o erro q vc falou né?

Então é isso mesmo :P

[Rodrigo Cesar Nascimento]

se for FK não tem como ser um valor nulo. se for mysql pq vc não usa auto increment e já é? explique melhor a situação. =)

[]'s
Rodrigo César Costa do Nascimento
Se queres viver e comer como um cão, podes ir dormir lá para fora. Se queres viver como um ser humano, pega esse hashi! (Pai Mei)

[André da Silva Severino]

é FK + eu defini como NULL o campo, não é obrigatório o preenchimento desse valor

[Rodrigo Cesar Nascimento]

André explique melhor, porque nunca vi uma tabela com campo FK nulo.

[André da Silva Severino]

Tipo eu tenho 2 tabelas, uma tabela cliente e outra estilos.

Na tabela cliente tenho uma FK da tabela estilos.

Essa tabela estilos é alimentada por uma pessoa(psicologa) que adiciona o nome do estilo(analitico/etc..) e tem uma descrição de pontos negativos, positivos, melhorar, etc...

Na hora do cadastro do cliente ele seleciona o estilo pertinente a este cliente, ou seja, busca a chave estrangeira na tabela estilos, mas eu tive que deixar esse campo nulo (não obrigatório), porque tem alguns clientes onde o consultor nao fez 'contato' e então não sabe o estilo do mesmo, para fazer uma análise do cliente antes de oferecer/vender algo.

Basicamente é isso, por isso tive que deixar a FK nula.

[Rodrigo Cesar Nascimento]

égua, cara. foi mals. viajei. pra mim, li PK, mas era FK. auehuahuahuhaeuhaeu. aceita sim. põe NULL como default pelo banco mesmo e já é. quando for cadastrar, o banco vê o valor default. se não mandar nada e grava como NULL.

[Adir Kuhn]

ou você pode fazer uma entidade fraca para relacionar  essas duas entidades

Adir Kuhn

[Pedro Antonio Saraiva Junior]

Alguém leu o que eu escrevi :S

--
Pedro Saraiva

[felipe moraes]

Basta o campo da tabela permitir NULL como valor ..

'tabela_id' INT(11) NULL,

http://felipebastosweb.com.br
http://twitter.com/felipebastosweb

[Eduardo Kraus]

Ola

Em chave estrangeira não é possível definir valor nulo.

O que podes fazer é definir a chave "0" na tabela de referencia e usar valor padrão Zero. Mais isso é gambiarrrrrra....

Eduardo Kraus
Professor 
+55 48 8843-3423
kr...@eduardokraus.com
www.eduardokraus.com
www.twitter.com/EduardoKraus

Em 18 de agosto de 2011 08:42, André da Silva Severino <andredasil...@gmail.com> escreveu:

[Suissa]

Se esse valor pode ser NULL primeiramente não deveria ser uma chave estrangeira, no máximo um campo de referencia ae sim poderia usar NULL mas não VAZIO em campos INT.

2011/8/19 Eduardo Kraus <eduard...@gmail.com>

--
Jean C. Nascimento aka Suissa
WebDeveloper Sênior - PGS - SP

Blog - suissacorp.com.br/suissa/

NoSQL Evangelist - nosqlbr.com.br/

      

[André da Silva Severino]

Então isso de criar um campo 0 eu pensei, mas vai ficar mt gambiarra mesmo :( kkkkkkkkkk

Ele está salvando como NULL, certinho, mas é uma FK que está relacionando com outra tabela, isso é ruim ?

Ou eu teria que por como referencia ? Mas acho que já está como referencia esse valor :p

[Eduardo Kraus]

Isso Isso isso

Eduardo Kraus
Professor 
+55 48 8843-3423
kr...@eduardokraus.com
www.eduardokraus.com
www.twitter.com/EduardoKraus

[felipe moraes]

Vcs tão esquecendo teoria de banco ???

tem relação que permite vazio sim .. pode conferir em qualquer livro que fale de modelo lógico e físico.

um cliente pode ficar sem endereço se for conveniente .. clientes x enderecos

Tá má a coisa hein !!!

http://felipebastosweb.com.br
http://twitter.com/felipebastosweb

[felipe moraes]

Tab1<->Tab2

0..1 <-> 1..N

Isso é feito da forma que falei .. permitindo NULL

Em 19 de agosto de 2011 10:06, felipe moraes <feli...@gmail.com> escreveu:

Vcs tão esquecendo teoria de banco ???

tem relação que permite vazio sim .. pode conferir em qualquer livro que fale de modelo lógico e físico.

um cliente pode ficar sem endereço se for conveniente .. clientes x enderecos

Tá má a coisa hein !!!

[Adir Kuhn]

por isso eu sugeri uma terceira entidade

ficaria:


clientes  <--> relacao_clientes_estilos <--> estilos

vc só adiciona na relação o cliente que tiver estilo

Adir Kuhn

--

[Eduardo Kraus]

Ola

Uma coisa é poder. Outra é fazer.

É errado deixar sem relacionamento quando necessário relacionamento visto que será uma linha sem utilidade.

Vamos ver da seguinte forma:

Tenha a tabela usuário, relacionada a ela tenha a tabela endereço. um usuário pode ter vários endereços(Trabalho, casa, casa de férias, casa da sogra). Que adianta ter uma linha na tabela endereço que não tenha relacionamento a nenhum usuário? Este endereço apenas irá ocupar espaço no banco de dados....

Eduardo Kraus
Professor 
+55 48 8843-3423
kr...@eduardokraus.com
www.eduardokraus.com
www.twitter.com/EduardoKraus

Em 19 de agosto de 2011 10:06, felipe moraes <feli...@gmail.com> escreveu:

[André da Silva Severino]

Como assim Eduardo, nao seria ao contrario? ter os campo do endereco na tabela usuario, onde ae sim ficaria com colunas vazias, pois na tabela endereco teria apenas registros com FK obrigatorios...

No meu caso da forma que eu fiz, vai ter 1 campo vazio apenas.

Agr se eu criar uma outra tabela apenas para armzenar os clientes com estilo igual o Adir disse é vantasoso ? visto-que, vou ter que relacionar mais uma tabela em todas as consultas...

abraços

[Adir Kuhn]

bom essa é a ideia da quarta forma normal =D

Adir Kuhn

[André da Silva Severino]

ehaeheheaheahea

[Eduardo Kraus]

Campo endereço na tabela usuário não....

Seria tabela Endereço com chave estrangeira para a Usuário

Eduardo Kraus
Professor 
+55 48 8843-3423
kr...@eduardokraus.com
www.eduardokraus.com
www.twitter.com/EduardoKraus

[Cassiano Ricardo Mourão]

Se é endereço -> usuário, TODO endereço terá que pertencer a um usuário, obrigatoriamente e portanto, todo fk_id_usuario terá de ter um id_usuario respectivo na tabela de usuários.
Se é usuário -> endereço, onde fk_id_endereco for NULL, significa apenas que não existe endereço para aquele usuário.

[André da Silva Severino]

então Cassiano, fiz da segunda forma que vc exemplificou, acho que não tem como ser 'de outro jeito', desta forma achei + simples e funcional, então está correto fazer assim:

Se é usuário -> endereço, onde fk_id_endereco for NULL, significa apenas que não existe endereço para aquele usuário.

?

[Cassiano Ricardo Mourão]

Pode ser feito assim. Não está normalizado, mas como eu sempre digo e alguns já sabem... a normalização (nem todas as formas, óbvio) nem sempre é a melhor saída.

[Adir Kuhn]

Bom a melhor forma mesmo é só conhecendo a estrutura do banco,
pelo pouco exposto aqui a alternativa dada pelo Cassiano serve de buenas

mas caso em algum ponto você necessite fazer uma relação de N para N dessas entidades
não vai ter como escapar da normalização.

Boa sorte e abraços

Adir Kuhn

[felipe moraes]

Vale lembrar tambem que:

Campo estilo_id como int nao significa que essa seja a chave estrangeira no banco. É um campo int como outro qualquer....

Lembra como é o modelo fisico?

Create table ...
Estilo_id int(11) NULL,
Foreign key fk_estilo_id (estilo_id) reference estilo (id) ... algo assim .. nao lembro sintaxe do mysql agora ... Tem banco que se acrescenta a fk via alter table ...

Fk_estilo_id é o indice da chave estrangeira .. e nao o estilo_id .. como estao pensando ..

Vao estudar banco de dados .. pelo amor de Deus.

Recomendo Navathe :)

Em 19/08/2011 12:14, "Adir Kuhn" <adir...@gmail.com> escreveu:
> Bom a melhor forma mesmo é só conhecendo a estrutura do banco,
> pelo pouco exposto aqui a alternativa dada pelo Cassiano serve de buenas
>
> mas caso em algum ponto você necessite fazer uma relação de N para N dessas
> entidades
> não vai ter como escapar da normalização.
>
> Boa sorte e abraços
>
> Adir Kuhn
>
>
> Em 19 de agosto de 2011 11:45, Cassiano Ricardo Mourão <
> cassian...@gmail.com> escreveu:
>
>> Pode ser feito assim. Não está normalizado, mas como eu sempre digo e
>> alguns já sabem... a normalização (nem todas as formas, óbvio) nem sempre é
>> a melhor saída.
>>
>> Em 19 de agosto de 2011 11:43, André da Silva Severino <
>> andredasil...@gmail.com> escreveu:
>>
>> então Cassiano, fiz da segunda forma que vc exemplificou, acho que não tem
>>> como ser 'de outro jeito', desta forma achei + simples e funcional, então
>>> está correto fazer assim:
>>>
>>>

>>> *Se é usuário -> endereço, onde fk_id_endereco for NULL, significa apenas

>>> que não existe endereço para aquele usuário.

>>> *

>>> ?
>>>
>>> Em 19 de agosto de 2011 11:40, Cassiano Ricardo Mourão <
>>> cassian...@gmail.com> escreveu:
>>>
>>> Se é endereço -> usuário, TODO endereço terá que pertencer a um usuário,
>>>> obrigatoriamente e portanto, todo fk_id_usuario terá de ter um id_usuario
>>>> respectivo na tabela de usuários.
>>>> Se é usuário -> endereço, onde fk_id_endereco for NULL, significa apenas
>>>> que não existe endereço para aquele usuário.
>>>>
>>>>
>>>> Em 19 de agosto de 2011 11:23, Eduardo Kraus <eduard...@gmail.com>escreveu:
>>>>
>>>> Campo endereço na tabela usuário não....
>>>>>
>>>>> Seria tabela Endereço com chave estrangeira para a Usuário
>>>>>

>>>>> *
>>>>> Eduardo Kraus*

>>>>>>> *Eduardo Kraus*

>>>>>>> Professor
>>>>>>> +55 48 8843-3423
>>>>>>> kr...@eduardokraus.com
>>>>>>> www.eduardokraus.com
>>>>>>> www.twitter.com/EduardoKraus
>>>>>>>
>>>>>>>
>>>>>>> Em 19 de agosto de 2011 10:06, felipe moraes <feli...@gmail.com>escreveu:
>>>>>>>
>>>>>>>> Vcs tão esquecendo teoria de banco ???
>>>>>>>>
>>>>>>>> tem relação que permite vazio sim .. pode conferir em qualquer livro
>>>>>>>> que fale de modelo lógico e físico.
>>>>>>>>
>>>>>>>> um cliente pode ficar sem endereço se for conveniente .. clientes x
>>>>>>>> enderecos
>>>>>>>>
>>>>>>>> Tá má a coisa hein !!!
>>>>>>>>
>>>>>>>>
>>>>>>>> Em 19 de agosto de 2011 09:55, Eduardo Kraus <eduard...@gmail.com
>>>>>>>> > escreveu:
>>>>>>>>
>>>>>>>> Isso Isso isso
>>>>>>>>>

>>>>>>>>> *
>>>>>>>>> Eduardo Kraus*

>>>>>>>>> Professor
>>>>>>>>> +55 48 8843-3423
>>>>>>>>> kr...@eduardokraus.com
>>>>>>>>> www.eduardokraus.com
>>>>>>>>> www.twitter.com/EduardoKraus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Em 19 de agosto de 2011 09:44, Suissa <jnasc...@gmail.com>escreveu:
>>>>>>>>>
>>>>>>>>> Se esse valor pode ser NULL primeiramente não deveria ser uma chave
>>>>>>>>>> estrangeira, no máximo um campo de referencia ae sim poderia usar NULL mas
>>>>>>>>>> não VAZIO em campos INT.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2011/8/19 Eduardo Kraus <eduard...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Ola
>>>>>>>>>>>
>>>>>>>>>>> Em chave estrangeira não é possível definir valor nulo.
>>>>>>>>>>>
>>>>>>>>>>> O que podes fazer é definir a chave "0" na tabela de referencia e
>>>>>>>>>>> usar valor padrão Zero. Mais isso é gambiarrrrrra....

>>>>>>>>>>> *
>>>>>>>>>>> Eduardo Kraus*

>>>>>>>>>>> Professor
>>>>>>>>>>> +55 48 8843-3423
>>>>>>>>>>> kr...@eduardokraus.com
>>>>>>>>>>> www.eduardokraus.com
>>>>>>>>>>> www.twitter.com/EduardoKraus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Em 18 de agosto de 2011 08:42, André da Silva Severino <
>>>>>>>>>>> andredasil...@gmail.com> escreveu:
>>>>>>>>>>>
>>>>>>>>>>>> Bom dia pessoal, como vocês lidam com a situação de salvar
>>>>>>>>>>>> valores nulos(vazios) em campos do tipo inteiro ? E ainda por cima FK.
>>>>>>>>>>>>
>>>>>>>>>>>> Vocês criam um registro do tipo (Não definido) e depois faz uma
>>>>>>>>>>>> verificação se for vazio insere esse valor por default ?
>>>>>>>>>>>>

>>>>>>>>>>>> *Incorrect integer value: '' for column 'fk_id_clienteEstilo' at
>>>>>>>>>>>> row 1*

>>>>>>>>>> <http://www.linkedin.com/profile/view?id=46505642> <http://www.facebook.com/suissa>
>>>>>>>>>> <http://twitter.com/suissacorp> <http://www.delicious.com/suissa>
>>>>>>>>>> <jnasc...@gmail.com>

[felipe moraes]

Nao lembro do inicio, mas falaram de Usuario x Estilo ..

Onde usuario pode ter 0 ou 1 estilo, e estilo pode pertencer a 1 ou N usuarios.

É uma relacao 0..1 x 1..N entre estilo e usuario ..

Basta que o campo estilo_id da tabela usuario seja INT e permita NULL. Que como ja disse .. está correto.

Mas, como usuario com estilo_id fica esquisito, sugiro que esse relacionamento seja feito com a tabela perfil que terá um relacionamento 1x1 com usuario

Em 19/08/2011 12:14, "Adir Kuhn" <adir...@gmail.com> escreveu:

> Bom a melhor forma mesmo é só conhecendo a estrutura do banco,
> pelo pouco exposto aqui a alternativa dada pelo Cassiano serve de buenas
>
> mas caso em algum ponto você necessite fazer uma relação de N para N dessas
> entidades
> não vai ter como escapar da normalização.
>
> Boa sorte e abraços
>
> Adir Kuhn
>
>
> Em 19 de agosto de 2011 11:45, Cassiano Ricardo Mourão <
> cassian...@gmail.com> escreveu:
>
>> Pode ser feito assim. Não está normalizado, mas como eu sempre digo e
>> alguns já sabem... a normalização (nem todas as formas, óbvio) nem sempre é
>> a melhor saída.
>>
>> Em 19 de agosto de 2011 11:43, André da Silva Severino <
>> andredasil...@gmail.com> escreveu:
>>
>> então Cassiano, fiz da segunda forma que vc exemplificou, acho que não tem
>>> como ser 'de outro jeito', desta forma achei + simples e funcional, então
>>> está correto fazer assim:
>>>
>>>

>>> *Se é usuário -> endereço, onde fk_id_endereco for NULL, significa apenas

>>> que não existe endereço para aquele usuário.

>>> *

>>> ?
>>>
>>> Em 19 de agosto de 2011 11:40, Cassiano Ricardo Mourão <
>>> cassian...@gmail.com> escreveu:
>>>
>>> Se é endereço -> usuário, TODO endereço terá que pertencer a um usuário,
>>>> obrigatoriamente e portanto, todo fk_id_usuario terá de ter um id_usuario
>>>> respectivo na tabela de usuários.
>>>> Se é usuário -> endereço, onde fk_id_endereco for NULL, significa apenas
>>>> que não existe endereço para aquele usuário.
>>>>
>>>>
>>>> Em 19 de agosto de 2011 11:23, Eduardo Kraus <eduard...@gmail.com>escreveu:
>>>>
>>>> Campo endereço na tabela usuário não....
>>>>>
>>>>> Seria tabela Endereço com chave estrangeira para a Usuário
>>>>>

>>>>> *
>>>>> Eduardo Kraus*

>>>>>>> *Eduardo Kraus*

>>>>>>> Professor
>>>>>>> +55 48 8843-3423
>>>>>>> kr...@eduardokraus.com
>>>>>>> www.eduardokraus.com
>>>>>>> www.twitter.com/EduardoKraus
>>>>>>>
>>>>>>>
>>>>>>> Em 19 de agosto de 2011 10:06, felipe moraes <feli...@gmail.com>escreveu:
>>>>>>>
>>>>>>>> Vcs tão esquecendo teoria de banco ???
>>>>>>>>
>>>>>>>> tem relação que permite vazio sim .. pode conferir em qualquer livro
>>>>>>>> que fale de modelo lógico e físico.
>>>>>>>>
>>>>>>>> um cliente pode ficar sem endereço se for conveniente .. clientes x
>>>>>>>> enderecos
>>>>>>>>
>>>>>>>> Tá má a coisa hein !!!
>>>>>>>>
>>>>>>>>
>>>>>>>> Em 19 de agosto de 2011 09:55, Eduardo Kraus <eduard...@gmail.com
>>>>>>>> > escreveu:
>>>>>>>>
>>>>>>>> Isso Isso isso
>>>>>>>>>

>>>>>>>>> *
>>>>>>>>> Eduardo Kraus*

>>>>>>>>> Professor
>>>>>>>>> +55 48 8843-3423
>>>>>>>>> kr...@eduardokraus.com
>>>>>>>>> www.eduardokraus.com
>>>>>>>>> www.twitter.com/EduardoKraus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Em 19 de agosto de 2011 09:44, Suissa <jnasc...@gmail.com>escreveu:
>>>>>>>>>
>>>>>>>>> Se esse valor pode ser NULL primeiramente não deveria ser uma chave
>>>>>>>>>> estrangeira, no máximo um campo de referencia ae sim poderia usar NULL mas
>>>>>>>>>> não VAZIO em campos INT.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2011/8/19 Eduardo Kraus <eduard...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Ola
>>>>>>>>>>>
>>>>>>>>>>> Em chave estrangeira não é possível definir valor nulo.
>>>>>>>>>>>
>>>>>>>>>>> O que podes fazer é definir a chave "0" na tabela de referencia e
>>>>>>>>>>> usar valor padrão Zero. Mais isso é gambiarrrrrra....

>>>>>>>>>>> *
>>>>>>>>>>> Eduardo Kraus*

>>>>>>>>>>> Professor
>>>>>>>>>>> +55 48 8843-3423
>>>>>>>>>>> kr...@eduardokraus.com
>>>>>>>>>>> www.eduardokraus.com
>>>>>>>>>>> www.twitter.com/EduardoKraus
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Em 18 de agosto de 2011 08:42, André da Silva Severino <
>>>>>>>>>>> andredasil...@gmail.com> escreveu:
>>>>>>>>>>>
>>>>>>>>>>>> Bom dia pessoal, como vocês lidam com a situação de salvar
>>>>>>>>>>>> valores nulos(vazios) em campos do tipo inteiro ? E ainda por cima FK.
>>>>>>>>>>>>
>>>>>>>>>>>> Vocês criam um registro do tipo (Não definido) e depois faz uma
>>>>>>>>>>>> verificação se for vazio insere esse valor por default ?
>>>>>>>>>>>>

>>>>>>>>>>>> *Incorrect integer value: '' for column 'fk_id_clienteEstilo' at
>>>>>>>>>>>> row 1*

>>>>>>>>>> <http://www.linkedin.com/profile/view?id=46505642> <http://www.facebook.com/suissa>
>>>>>>>>>> <http://twitter.com/suissacorp> <http://www.delicious.com/suissa>
>>>>>>>>>> <jnasc...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

[Pedro Antonio Saraiva Junior]

Uau Bem vindo ao SQL Grupo Brasil

Pedro Saraiva