null vs vacio

[bellacord]

alguien me explica la diferencia entre un campo null y un vacio... o me pasan un link con info?

[enerone1]

Cuando definis un campo como null tenes la posibilidad de utilizar funciones como, IS NULL o IS NOT NULL, que te van a dar siempre un booleano como resultado. Esto es mas reapido que un select en el que preguntas por el contenido y despues lo analizas

Suerte
Enermedia

[bellacord]

si, pero cual es la diferencia en tenerlo vacio?

[MACGREGOR]

Hola.
Si insertas en un campo de una tabla 'NULL' insertas un string de 4 letras.
Si insertas '' insertas el valor NULL.
Si en una tabla de 5 campos insertas 4 valores y el último lo ignoras por completo insertas en realidad NULL.

Vacío es igual a NULL. Un campo en una tabla tiene un valor de un cierto tipo (numérico, carácter...) o tiene NULL que és la ausencia de valor.

Otra cosa es el resultado de una consulta. Si no hay resultado no devuelve nada, pero nada de nada para que no se confunda con un resultado NULL.

Por ejemplo, supongamos que tienes una tabla de usuarios con su teléfono.
Si haces una consulta sobre el teléfono del usuario "José luis" y el resultado es NULL significa que no existe el télefono de ese usuario.
Sin envargo, si no existe el usuario la consulta te devolverá LA NADA.

Dependiendo del cliente que utilices para conectar con tu Base de Datos es muy posible que en algún sitio te ponga la cantidad de registros obtenidos.
En un caso te enseña los resultados vacíos y te dice "0 rows selected" (NADA DE NADA) y en otro te enseña los resultados vacíos pero te dice "1 row selected" (o Selected 1 of 1... vamos que te muestra un campo NULO=NULL)

Espero haber aclarado tu duda.

[Mithrandir]

Macgregor, me temo que estás en un error. '' (cadena vacía) es diferente de NULL.

Precisamente ahí está el asunto. NULL siginifica que el campo no tiene valor (no está definido, ausencia total).

'' indica que hay una cadena vacía, pero cadena al fin. O sea, existe algo: una cadena.

Mismo caso con el 0. "Cero unidades" es diferente de "ausencia de valor"

De esto se deriva que no puedas usar condiciones (where) preguntando si "campo = null", sino que existe la sentencia especial "campo is null"

[Developer9]

NULL es nada... es como los astronautas en el espacio

[foo]

Iniciado por Mithrandir

Macgregor, me temo que estás en un error. '' (cadena vacía) es diferente de NULL.

talvez lo dice porque oracle considera las cadenas vacias como nulas

[Developer9]

Cierto... en SQL Server no es lo mismo por ejemplo en los campos de un INSERT INTO meterle un NULL a dos comillas simples seguidas --> ''

[bellacord]

ok si el null es q no se inserta valores algunos, tal como dijeron en el ejemplo de cero, que seria null, y q seria el caso entonces de "vacio"

[PequeñoMauro]

Iniciado por foo

talvez lo dice porque oracle considera las cadenas vacias como nulas

Bueno, Oracle no considera las cadenas vacías como nulas, ya lo viví, jejeje.
bellacord, sería bueno que leas nuevamente el post de Mithrandir, ahi te explica la diferencia.
Saludos

[MACGREGOR]

Mithrandir
Macgregor, me temo que estás en un error. '' (cadena vacía) es diferente de NULL.
foo
talvez lo dice porque oracle considera las cadenas vacias como nulas
PequeñoMauro
Bueno, Oracle no considera las cadenas vacías como nulas, ya lo viví, jejeje.

Efectivamente acostumbro a trabajar con Oracle.
He provado las siguientes instrucciones para ver si dejamos claro algo.

Los 4 primeros campos de la tabla de usuarios están declarados como NOT NULL.
T.ID_USER, T.LEADER y T.BANED son campos númericos, el resto varchar2 (strings o cadenas, como prefieran llamarlo)

insert into MICRO.TBL_USER T (T.ID_USER, T.USERNAME, T.NAME, T.PASSWORD, T.LEADER, T.BANED)
values ( 500,'',' ',' ','',NULL)

Intentando insertar en el segundo campo de la tabla (T.USERNAME, un campo NOT NULL) una cadena vacía ''.
Resultado: ORA-01400:no se puede realizar una inserción NULL en ("MICRO"."TBL_USER"."USERNAME")
Se quejó insertando la cadena '' vacía y el error habla de NULL!!

modificamos de la sentencia sql la parte del values por :values ( 500,'500',' ',' ','',NULL)
De esta manera intentamos insertar en el campo T.LEADER (numérico) una cadena vacía ''.
Resultado: 1 row inserted

No dió error, por tanto no hubo incompatibilidad de tipos, ¿se insertó una cadena vacía en un campo numérico? ¿ o se insertó NULL????

Comprovamos el contenido con la siguiente consulta:
Select T.ID_USER
From MICRO.TBL_USER T
where t.LEADER is null

Resultado: ID_USER = 500

Por tanto (en ORACLE) creo que queda claro que NULL (sin comillas) es ausencia de valor, 'NULL' una cadena de 4 carácteres, y '' (la cadena vacía) también es ausencia de valor.

No sabía que otros sistemas gestores se comportaban de forma un tanto diferente, ahunque tampoco me sorprende que grupos distintos de personas implementen ligeras variaciones en distintos SGBD's.

PequeñoMauro creo que pensabas en otro SGBD cuando mandaste tu mensaje.

[foo]

Iniciado por MACGREGOR

No sabía que otros sistemas gestores se comportaban de forma un tanto diferente, ahunque tampoco me sorprende que grupos distintos de personas implementen ligeras variaciones en distintos SGBD's.

me parece, que el estandar sql no define que una cadena vacia equivalga a null.

[PequeñoMauro]

Iniciado por MACGREGOR

Por tanto (en ORACLE) creo que queda claro que NULL (sin comillas) es ausencia de valor, 'NULL' una cadena de 4 carácteres, y '' (la cadena vacía) también es ausencia de valor.

No sabía que otros sistemas gestores se comportaban de forma un tanto diferente, ahunque tampoco me sorprende que grupos distintos de personas implementen ligeras variaciones en distintos SGBD's.

PequeñoMauro creo que pensabas en otro SGBD cuando mandaste tu mensaje.

--------------------------------------------------------------------------------

Haciendo la prueba, tienes razón MACGREGOR. Lo que escribi fue por una experiencia con respecto a los NULL's.
Lo he probado tanto para números y caracteres y es el mismo resultado. Y bueno, también creo que confundi '' con ' '.
Vale la aclaración, y mi rectificación

[Mithrandir]

En SQL Server esa diferencia sí existe. Tanto que desde enterprise manager tienes una combinación de teclas especial para insertar NULL en lugar de dejar el '' que puedes haber colocado en un INSERT por separado.

Bueno conocer particularidades de otros manejadores

[oscarpt2184]

SOBRE TODO ESTO DEL NULL Y EL VACIO AUN NO COMPRENDO QUE HAY EN DIFERENCIA YO E TENIDO ALGUNOS DUDAS EJEM:
TABLA DE 2 CAMPOS NOMBRES Y APELLIDOS

AHORA YO HABIA MODIFICADO EN LA BASE DE DATOS MANUALMENTE HABIA BORRADO ALGUNOS APELLIDOS PERO NO EL REGISTRO OSEA TENIA : 100 nombres pero 13 con apellidos

NOMBRES APELLIDO
OSCAR TOLENTINO
MARCOS SANCHEZ
JUAN MANCO
.... los 13 registros con apeelidos

Y SOLO BORRE (TOLENTINO Y SANCHEZ) BORRE 2 APELLIDOS

NOMBRES APELLIDO
OSCAR
MARCOS
JUAN MANCO
.... los 13 registros con apeelidos


EN ANALIZAR DE CONSULTAS DE SQL COLOCO LA SIGUIENTE IONSTRUCCIOPN
SELECT * FROM TABLA1 -- EL RESULTADO ES OK(100 REGISTROS)
SELECT * FROM TABLA1 WHERE NOMBRE IS NULL --- EL RESUALTADO ES 85
SELECT * FROM TABLA1 WHERE NOMBRE = ' ' --- EL RESULTADO ES 2


AHORA LA PREGUNTA ES... POR QUE HACE ESA DIFERENCIA CUANDO EJECUTAS ESTAS INTRUCCIONES!!!!!!

POOR FAVOR SI ALGUIN PUEDE AYUDAR CON ESTO MI CORREO ES bus_enam hotmail

[Developer9]

Eso significa que ''<>NULL

NULL ni siquiera ocupa espacio, es como una variable declarada pero no utilizada.

'' es como cuando la instancias pero aun no guardas nada en ella.

Cuando tu borraste en dos registros los apellidos dichos campos no quedaron en NULL

[MACGREGOR]

Lo primero que deberías aclarar es que sistema gestor de BBDD utilizas.

Como se ha dicho en los mensajes anteriores algunos como ORACLE consideran la cadena vacía como NULL.

Otros SGBD's como Sql-Server no consideran la cadena vacía como un NULL (guardan un signo de final de cadena del estilo de \n o \n\r) por lo tanto guardan algo y el campo no es NULL.

Has hecho las siguientes pruebas:
SELECT * FROM TABLA1 -- EL RESULTADO ES OK(100 REGISTROS)
SELECT * FROM TABLA1 WHERE NOMBRE IS NULL --- EL RESUALTADO ES 85
SELECT * FROM TABLA1 WHERE NOMBRE = ' ' --- EL RESULTADO ES 2

Supongo que cuando has puesto NOMBRE querías decir APELLIDO, has dicho que habías borrado apellidos no nombres...
En tu última consulta has puesto un espacio en blanco entre las comillas simples.... eso no es NULL es una cadena con un espacio en blanco!!

Que significa el resultado de tus consultas?
1- tienes 100 registros.
2- 85 registros tienen "APELLIDO" nulo (NULL) sin apellido, vacíos
3- 2 registros tienen "APELLIDO" = "espacio en blanco"

(También decías que habías dejado en la tabla 13 registros con nombre y apellido)

Conclusión: 85 nulos + 2 con espacio en blanco + 13 con apellidos = 100.

[luise32]

Excelente analisis y deduccion, 100% de acuerdo con eso

[oscarpt2184]

Mmmmmm...
Disclupen Pero No Me Explique Bien!!!!!!!!
Espero Que Ahora Me Entiendan

Vemos Me Explico Mejor.
Yo E Trabajado En Sql 2000 ' Este El Manejdaro De Base De Datos

Ahora Tenemos Un Tabla "clientes" Con 2 Campos (nombres Y Apellido)con 20 Registros Y Que En El Campo Apellidos Hay 10registros Que Tienen Osea

De Los 20 Registros 10 Tienen Apellidos Y El Resto No, Que Estan Como Nulo. Ahora Ingrese A La Base De Datos Y De Los 10 Registros Que Tiene Apellido Borre 5 Mas No Elimine El Registro Solo El Apeelido
Y Ahi Mismo Cuando Se Observa Que El Campo Borrado No Se Pone Null.. Y Ahora Voy Al Analizador De Consulta Y Ejecuto Estas Instrucciones

Select*from Clientes ' Resultado 20 Registros
Select*from Clientes Where Apellido Is Null ' Resultado 10 Registro
Select*from Clientes Where Apellido<>'' ' Resultado 5
Select*from Clientes Where Apellido='' ' Resultado 5

('') Son Apostofres

Asi Quedo La Tabla Observen!!!!!!

__________________________________________________ __
|nombre |apellido |
------------------------------------------------------------
|nombre1 |apellido1 |
|nombre2 |apellido2 |
|nombre3 |apellido3 |
|nombre4 |apellido4 |
|nombre5 |apellido5 |
|nombre6 | |
|nombre7 | |
|nombre8 | |
|nombre9 | |
|nombre10 | |
|nombre11 |<null> |
|nombre12 |<null> |
|nombre13 |<null> |
|nombre14 |<null> |
|nombre15 |<null> |
|nombre16 |<null> |
|nombre17 |<null> |
|nombre18 |<null> |
|nombre19 |<null> |
|nombre20 |<null> |


Espero Que Ahora Si Me Aya Dejado Entender Y Pes Se De Un Reultado Entre La Diferencia De Un Null Y Vacio

Gracias A Todos Que Den Un Resultado

[clonator]

Hola Soy nuevo en el foro, estoy completamente de acuerdo con mcgregor, yo tambien soy dba de oracle, en oracle hay una funcion llamada DUMP con la que puedes ver la informacion que tienes en base de datos tal cual esta almacenada de forma binaria, decimal o hexadecimal. un ejemplo seria

SELECT dump(columna,1016) from table;

con esta instruccion te devuelve los valores de la columna 'columna' pero en formato hexadecimal asi puedes ver realmente que es lo que tienes almacenado en tu base de datos. Desconozco si hay una funcion parecida en sqlServer, seria bueno que googlearas por ahi.

Por otro lado '' no es lo mismo que ' ' la primera es una cadena vacia y la segunda es una cadena que equivale a "un espacio"

[Kelpie]

Lo siguiente se refiere solo a SGBD que diferencien entre vacío y nulo

La diferencia entre un campo vacío y uno nulo es la virginidad del campo. Un campo nulo está vírgen. Una vez que se carga un valor (cualquier valor) deja de ser nulo. Luego, por más que quieras vaciarlo no volverá a ser virgen (nulo).


OscarRpt, los resultados que obtienes es fiel reflejo de lo que tienes en la tabla:

10 registros con apellido nulo (no inicializado, campo vírgen)
5 registros con apellido vacío (inicializado pero borrado. NO vírgen)
5 registros con apellido.

De todas maneras, un campo puede volver a ser vírgen (nulo):

Update clientes set apellido=Null WHERE apellido=""

[kunndry]

Voy a animarme a opinar tambien...probablemente liando más la cosa, jeje.

Yo no aconsejaria a nadie tratar la cadena vacia y la nula de igual manera, independientemente de que las ultimas versiones de oracle(imagino que seran las ultimas) las traten asi.

De esto no estoy seguro al 100%, pero creo recordar que oracle 8 no las trataba igual (No tengo ni idea de por cual van, no trabajo con Oracle).

Alguien por arriba comento que creia que el Standard no define vacio y null equivalente, y yo estoy con el.

Si se tratan de igual manera, si en un futuro se tiene que migrar de una base de datos a otra, puede dar problemas.

Y como ya han dicho, el null es que se desconoce el valor, y la cadena vacia es que se conoce y es vacio.

Un ejemplo, podria ser, un listado de clientes, y en el campo telefono, null o vacio. Null seria que no sabes si tiene numero de telefono, y vacio que no lo tiene (Esto es un ejemplo algo tonto, pero para aclarar ideas puede servir).

Un saludo a todos!

[MACGREGOR]

Veo que se ha vuelto a reabrir este post sobre NULL vs Vacio.

He releido los mensajes y creo que queda muy clara la diferencia entre NULL y Vacio.

En los últimos mensajes únicamente se genera polémica en torno a la cadena vacía.
Creo que también quedó claro que en ORACLE equivale a NULL y en Sql-Server NO. (provablemente en otros SGBD's tampoco).

Se ha hablado de si se ha definido de una manera o de otra en el standard sql...

Lo cierto es que a efectos prácticos es indiferente.

Lo importante es saber como dice Mithrandir
En SQL Server esa diferencia sí existe. Tanto que desde enterprise manager tienes una combinación de teclas especial para insertar NULL en lugar de dejar el '' que puedes haber colocado en un INSERT por separado.
Bueno conocer particularidades de otros manejadores

También se ha hablado de migrar una DDBB a otra...
Si tienes una DDBB ORACLE da lo mismo si insertas cadenas vacias o NULL's el SGBD inserta NULL de todas formas, lo importante es saber que una vez termines de migrar los datos (a Sql-Server por ej.) no tendrás ninguna cadena vacía todo nulls.
Y si la migración es hacia ORACLE debes saber que tendrás registros con NULL y otros con un carácter "extraño" que antes significaba cadena vacia.(provablemente un \n o \n\r como ya dije en otro mensaje anterior).

Siento mucho si me repito, pero lo importante es el "conocimiento", saber el comportamiento del SGBD con el que trabajas y saber las diferencias que tiene con otros.

Obviamente todo el mundo tiene derecho a opinar que forma le parece más razonable. Personalmente me resulta muy cómodo como lo maneja ORACLE, pero veo más lógica la otra forma.