Int, Bool vs NULL
pepito
Alfredo Novoa
>Hola compañeros....
>
>¿Es imposible en .NET a un valor entero o booleano asignarle un valor nulo que permita diferenciar el valor 0 o false respectivamente?
No lo es, aunque los nulos no son nunca buena cosa.
http://msdn2.microsoft.com/en-us/library/2cf62fcy.aspx
Saludos
Rolando
int? num = null;
if (num.HasValue == true)
{
System.Console.WriteLine("num = " + num.Value);
}
else
{
System.Console.WriteLine("num = Null");
}
Saludos
Ricardo Gersan
> On Thu, 7 Dec 2006 15:55:12 -0500, "pepito" <pep...@pepito.com> wrote:
>
> > Hola compañeros....
> >
> > ¿Es imposible en .NET a un valor entero o booleano asignarle un
> > valor nulo que permita diferenciar el valor 0 o false
> > respectivamente?
>
> No lo es, aunque los nulos no son nunca buena cosa.
>
No entiendo eso? Que quiere decir? Que no debemos utilizar los tipos
nulos?
Alfredo Novoa
Hola Ricardo
On Fri, 08 Dec 2006 00:58:40 -0800, "Ricardo Gersan"
<ric...@elsistec.co> wrote:
>> No lo es, aunque los nulos no son nunca buena cosa.
>>
>
>No entiendo eso? Que quiere decir? Que no debemos utilizar los tipos
>nulos?
Para lo único que pueden servir los tipos anulables es para leer datos
de tablas que tengan nulos. Pero las tablas tampoco deberían tener
nulos excepto para evitar males mayores.
Saludos
Alfredo
Ricardo Gersan
> Para lo único que pueden servir los tipos anulables es para leer datos
> de tablas que tengan nulos. Pero las tablas tampoco deberían tener
> nulos excepto para evitar males mayores.
Porque no me puede servir saber si una variable esta inicializado o no?
O en algún momento quiero asignarle un valor nulo? Que tiene de mal eso?
Quien esta restringiendo el uso de valores nulos a tablas? POrque
debería ser así?
--
RFOG
wrote:
>
>> Para lo único que pueden servir los tipos anulables es para leer datos
>> de tablas que tengan nulos. Pero las tablas tampoco deberían tener
>> nulos excepto para evitar males mayores.
>
> Porque no me puede servir saber si una variable esta inicializado o no?
> O en algún momento quiero asignarle un valor nulo? Que tiene de mal eso?
>
Realmente absolutamente nada, y en C++ es lo habitual, y en C++/CLI casi
también.
Y teniendo código como este:
if(mivar!=null && mivar.valor!=0)
te ahorrarás algún susto... El evaluador va de izquierda a derecha, si
mivar es nulo ya no continua evauluando, y si no lo es entocnes evalua lo
siguiente. Evidentemente no hay que hacerlo siempre, pero cuando tengas la
duda...
Y es algo que no recomiendo yo, sino varios grandes programadores, como
por ejemplo Stroustrup.
> Quien esta restringiendo el uso de valores nulos a tablas? POrque
> debería ser así?
>
--
Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
========================================
El verdadero modo de no saber nada es aprenderlo todo a la vez.
-- Aurore Dupín. (George Sand). (1804-1876) Novelista francesa.
Ricardo Gersan
> On Tue, 12 Dec 2006 23:01:31 +0100, Ricardo Gersan
> <ric...@elsistec.co> wrote:
>
> >
> > > Para lo único que pueden servir los tipos anulables es para leer
> > > datos de tablas que tengan nulos. Pero las tablas tampoco
> > > deberían tener nulos excepto para evitar males mayores.
> >
> > Porque no me puede servir saber si una variable esta inicializado o
> > no? O en algún momento quiero asignarle un valor nulo? Que tiene
> > de mal eso?
> >
>
> Realmente absolutamente nada, y en C++ es lo habitual, y en C++/CLI
> casi también.
>
Por ello, y estoy de acuerdo en lo que dices. Lo que no entiendo es
porque dice que no debe utilizarse. TOdavia no he visto el motivo,
salvo que dice que esta mal, pero eso para mi no es motivo.
--
RFOG
wrote:
Sin querer entrar en discusiones, el amigo Alfredo Novoa es bastante
fundamentalista en el sentido de que lo que él dice es cierto sin más.
Alfredo Novoa
<ric...@elsistec.co> wrote:
>
>> Para lo único que pueden servir los tipos anulables es para leer datos
>> de tablas que tengan nulos. Pero las tablas tampoco deberían tener
>> nulos excepto para evitar males mayores.
>
>Porque no me puede servir saber si una variable esta inicializado o no?
Por que si no inicializas las variables el programa no compila.
>O en algún momento quiero asignarle un valor nulo? Que tiene de mal eso?
Pues que no sirve para nada. Un nulo en realidad no es un valor, sino
que es una marca que indica que la variable no tiene ningún valor.
Siempre hay una forma mejor de hacer las cosas sin usar nulos.
>Quien esta restringiendo el uso de valores nulos a tablas?
Nadie, pero los nulos de las tablas son la razón por la que se
añadieron los nulos a C#.
Los nulos son un error de diseño de SQL y ensucian el lenguaje C# pero
incorporarlos a C# puede hacer que sea más fácil trabajar con tablas
que tengan nulos.
Saludos
Alfredo Novoa
<zephryn...@quitame.gmail.com> wrote:
>> Porque no me puede servir saber si una variable esta inicializado o no?
>> O en algún momento quiero asignarle un valor nulo? Que tiene de mal eso?
>
>Realmente absolutamente nada, y en C++ es lo habitual, y en C++/CLI casi
>también.
El puntero nulo de C++ y C# tiene muy poco que ver con los nuevos
tipos anulables de C#. No hay que confundir los tipos valor con los
tipos referencia.
Saludos
Alfredo Novoa
<ric...@elsistec.co> wrote:
>Por ello, y estoy de acuerdo en lo que dices. Lo que no entiendo es
>porque dice que no debe utilizarse. TOdavia no he visto el motivo,
>salvo que dice que esta mal, pero eso para mi no es motivo.
Yo no he dicho que no deban utilizarse, lo que he dicho es que solo
sirven para tratar con nulos que vienen de una base de datos y que los
nulos nunca son una buena cosa. Y esto no incluye al puntero nulo de
muchos lenguajes, que es un tipo completamente diferente de nulo.
Si hacemos:
bool? b = null;
y
object o = null;
Son dos tipos completamente diferentes de nulos.
Esto se podría considerar como un error de diseño del lenguaje: dos
cosas muy diferentes con el mismo nombre.
Saludos
Ricardo Gersan
> sirven para tratar con nulos que vienen de una base de datos y que los
Pero porque? El mismo ejemplo que yo he dado no se basa en datos de una
base de datos.
> bool? b = null;
>
> y
>
> object o = null;
>
y?
Ricardo Gersan
Pues por eso mismo no entiendo porque dices que esta mal.
--
Ricardo Gersan
> que es una marca que indica que la variable no tiene ningún valor.
> Siempre hay una forma mejor de hacer las cosas sin usar nulos.
>
A mi me ha servido bastante. No creo que un motivo de no usarlo sea
porque no te haya servido a ti.
> Nadie, pero los nulos de las tablas son la razón por la que se
> añadieron los nulos a C#.
>
Podría ser, no lo se. Pero contribyen a más ventajas.
> Los nulos son un error de diseño de SQL y ensucian el lenguaje C# pero
> incorporarlos a C# puede hacer que sea más fácil trabajar con tablas
> que tengan nulos.
>
Son un error de diseño de SQL? Como es eso?
RFOG
Una cosa son los tipos anulables de C# y otra variables del tipo que sean
que estén asignadas a null, y creo que el amigo Ricardo se refiere a eso.
>
>>> Para lo único que pueden servir los tipos anulables es para leer datos
>>> de tablas que tengan nulos. Pero las tablas tampoco deberían tener
>>> nulos excepto para evitar males mayores.
>> Porque no me puede servir saber si una variable esta inicializado o no?
>Por que si no inicializas las variables el programa no compila.
>
Escenario: interop con un componente COM o ActiveX que no se asigne,
variables internas a él que no se asignen o que sean null de primeras, lo
mimso para interop con código nativo. Hay funciones del Win32 en las que
tienes que llamar con una estructura asignada a NULL para que la función
te devuelva el tamaño a asignar, etc.
>> O en algún momento quiero asignarle un valor nulo? Que tiene de mal eso?
>Pues que no sirve para nada. Un nulo en realidad no es un valor, sino
> que es una marca que indica que la variable no tiene ningún valor.
> Siempre hay una forma mejor de hacer las cosas sin usar nulos.
>
La diferencia entre esto
string hola=null
y
string hola=""
Consiste en que el primer hola sólo ocupa espacio en la pila, y es
segundo, tanto en la pila como en el montículo, y en determinadas
circunstancias podría ser interesante no tener nada asignado y mantener
esa memoria libre (léase PDAs, dispositivos CE...)
Luego nos quejamos de que una aplicación tarda dos horas en cargar y ocupa
50 MB de RAM...
>> Quien esta restringiendo el uso de valores nulos a tablas?
>Nadie, pero los nulos de las tablas son la razón por la que se
> añadieron los nulos a C#.
>Los nulos son un error de diseño de SQL y ensucian el lenguaje C# pero
> incorporarlos a C# puede hacer que sea más fácil trabajar con tablas
> que tengan nulos.
Aquí no entro porque NPI.
>
> Saludos
Alfredo Novoa
<ric...@elsistec.co> wrote:
>> Yo no he dicho que no deban utilizarse, lo que he dicho es que solo
>> sirven para tratar con nulos que vienen de una base de datos y que los
>
>Pero porque? El mismo ejemplo que yo he dado no se basa en datos de una
>base de datos.
Yo no he visto ningún ejemplo tuyo.
Saludos
Alfredo Novoa
<ric...@elsistec.co> wrote:
>Alfredo Novoa wrote:
>
>> On Tue, 12 Dec 2006 23:21:16 +0100, RFOG
>> <zephryn...@quitame.gmail.com> wrote:
>>
>> >> Porque no me puede servir saber si una variable esta inicializado
>> o no? >> O en algún momento quiero asignarle un valor nulo? Que
>> tiene de mal eso?
>> >
>> > Realmente absolutamente nada, y en C++ es lo habitual, y en C++/CLI
>> > casi también.
>>
>> El puntero nulo de C++ y C# tiene muy poco que ver con los nuevos
>> tipos anulables de C#. No hay que confundir los tipos valor con los
>> tipos referencia.
>Pues por eso mismo no entiendo porque dices que esta mal.
Pues yo tampoco te entiendo a ti. El ejemplo de RFOG no es aplicable
aquí.
Saludos
Alfredo Novoa
<ric...@elsistec.co> wrote:
>> Pues que no sirve para nada. Un nulo en realidad no es un valor, sino
>> que es una marca que indica que la variable no tiene ningún valor.
>> Siempre hay una forma mejor de hacer las cosas sin usar nulos.
>>
>
>A mi me ha servido bastante. No creo que un motivo de no usarlo sea
>porque no te haya servido a ti.
¿Puedes poner algún ejemplo?
>> Los nulos son un error de diseño de SQL y ensucian el lenguaje C# pero
>> incorporarlos a C# puede hacer que sea más fácil trabajar con tablas
>> que tengan nulos.
>
>Son un error de diseño de SQL? Como es eso?
Es un tema sobre el que han corrido ríos de tinta.
Saludos
Ricardo Gersan
> Pues yo tampoco te entiendo a ti. El ejemplo de RFOG no es aplicable
> aquí.
>
Ok, gracias. Veo que no puede ofrecerme una solución basada en hechos.
Hasta luego.
--
Ricardo Gersan
>
Algún enlace en particular?
--
Alfredo Novoa
<ric...@elsistec.co> wrote:
>Ok, gracias. Veo que no puede ofrecerme una solución basada en hechos.
¿Una solución a que?
Los programadores han vivido durante décadas sin tipos anulables sin
NINGÚN PROBLEMA excepto cuando se leen tablas con nulos de una base de
datos.
Saludos.
Alfredo Novoa
Aquí tienes algo:
http://www.dbdebunk.com/page/page/2928212.htm
http://en.wikipedia.org/wiki/Relational_model#SQL_standard
Si sabes lo que fue el System R esto puede ser bastante indicativo:
We did nearly fall into the "nulls" trap, but thankfully veered away
from it at the last minute, under advice from Chris Date, Stephen Todd
(of the ISBL team) and, wait for it ... System R's Bruce Lindsay!
http://www.mcjones.org/System_R/bs12.html
Saludos
Ricardo Gersan
Eso es su argumento? Y han vivido décadas sin genéricos, décadas sin
otras caracterísitcas y eso los hace inútiles?
Ricardo Gersan
datos, como cuando yo leo un valor, debe interpretar si hay un valor
asignado a ese valor o no?
--
Alfredo Novoa
Los genéricos existen desde los 70 y su utilidad es fácil de explicar
poniendo ejemplos, pero nadie ha dicho aun para que pueden servir los
tipos anulables además de para leer tablas. Si no hay ejemplos será
por algo.
Saludos
Alfredo Novoa
Si no hay nulos, siempre que leas un atributo de una tupla obtendrás
un valor, lo cual facilita las cosas y reduce la probabilidad de
errores.
La lógica de tres valores es una pesadilla y además ni siquiera tiene
un tratamiento consistente en SQL.
http://www.dbazine.com/ofinterest/oi-articles/pascal27
http://www.dbdebunk.com/page/page/1706814.htm
Saludos
RFOG
tu, no entiendo su motivo ni por qué están, y por el otro el uso y la
posibilidad de asignar nulo a una variable, ¿no?
Realmente el único sentido fuera del tema de acceso a datos, que desconozco
casi completamente, de los "nullables" es el tener un valor más fuera del
dominio de la variable para que ésta pueda contener cualquiera de sus
posibles valores *más* el nulo, de este modo no tenemos que reservar un
posible valor para indicar "elemento no válido" o "elemento erróneo", o como
queramos llamarlo.
Respecto a los nulos dentro de una base de datos, si es lo que creo -no
tengo tiempo para mirarlo ahora-, creo, y sólo creo, que pudieran ser
útiles.
Si un campo nulo o asignado a nulo es aquel que, una vez obtenido un
registro de una base de datos, no apunta a nada o no contiene nada, creo que
tiene mucho sentido.
Imaginemos una base de datos con todos los españoes: 40 millones de
registros, con un campo memo con comentarios policiales. El 99,99% de los
españoles no tienen...
Ahora imaginemos que ese campo debe contener un valor, que indice "vacío".
Si no recuerdo mal, son al menos 10 bytes para apuntar al memo. 10 x 40 x
10^6 bytes que nos ahorramos en la base de datos, sin contar con el propio
campo memo, que aunque esté vacío debe contener al menos un cero para
indicarlo (si no sería absurdo que algo apuntara a nada).
Es mi opinión.
--
Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
========================================
El verdadero modo de no saber nada es aprenderlo todo a la vez.
-- Aurore Dupín. (George Sand). (1804-1876) Novelista francesa.
"Alfredo Novoa" <alfred...@hotmail.com> wrote in message
news:dpc0o2huk8reaplph...@4ax.com...
Alfredo Novoa
<zephryn...@QUITAME.gmail.com> wrote:
>Se está hablando por un lado de los "nullables", que personalmente, y como
>tu, no entiendo su motivo ni por qué están
Bueno, yo si lo entiendo y se por que están: por que en SQL hay nulos.
Me parecen una guarrada, pero el culpable es SQL.
>, y por el otro el uso y la
>posibilidad de asignar nulo a una variable, ¿no?
Si.
>Realmente el único sentido fuera del tema de acceso a datos, que desconozco
>casi completamente, de los "nullables" es el tener un valor más fuera del
>dominio de la variable para que ésta pueda contener cualquiera de sus
>posibles valores *más* el nulo, de este modo no tenemos que reservar un
>posible valor para indicar "elemento no válido" o "elemento erróneo", o como
>queramos llamarlo.
Ya, pero eso normalmente es otra chapuza. Eso se implementa mejor
estructurando bien el código.
Un tipo nullable es algo como esto:
struct Nullable<T>
{
public bool HasValue;
public T Value;
}
Pero además se meten en líos innecesarios con la lógica de tres
valores y redefinen los operadores aritméticos y demás.
>Respecto a los nulos dentro de una base de datos, si es lo que creo -no
>tengo tiempo para mirarlo ahora-, creo, y sólo creo, que pudieran ser
>útiles.
La mayoría de los expertos en bases de datos piensan lo contrario.
Tienes bastante información en los enlaces que he dejado.
>Si un campo nulo o asignado a nulo es aquel que, una vez obtenido un
>registro de una base de datos, no apunta a nada o no contiene nada, creo que
>tiene mucho sentido.
En el Modelo Relacional no tienen ningún sentido. El Modelo Relacional
es una aplicación directa de la lógica de predicados y la teoría de
conjuntos. Si metes un nulo en una tabla entonces la tabla deja de
representar a una relación matemática y esto produce una serie de
consecuencias indeseables que están bien descritas en la literatura.
En la práctica los nulos causan montones de bugs. Yo personalmente he
tenido que corregir cientos de ellos, sin exagerar.
>Imaginemos una base de datos con todos los españoes: 40 millones de
>registros, con un campo memo con comentarios policiales. El 99,99% de los
>españoles no tienen...
>
>Ahora imaginemos que ese campo debe contener un valor, que indice "vacío".
¿Que tal una cadena de texto de longitud cero?
>Si no recuerdo mal, son al menos 10 bytes para apuntar al memo. 10 x 40 x
>10^6 bytes que nos ahorramos en la base de datos, sin contar con el propio
>campo memo, que aunque esté vacío debe contener al menos un cero para
>indicarlo (si no sería absurdo que algo apuntara a nada).
Estás confundiendo el modelo lógico con el modelo físico. Hay muchas
formas de implementar físicamente un modelo lógico. Un SGBD bien
implementado podría hacer que un memo con un texto de longitud cero
ocupase lo mismo que un nulo.
Saludos
RFOG
--
Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
========================================
El verdadero modo de no saber nada es aprenderlo todo a la vez.
-- Aurore Dupín. (George Sand). (1804-1876) Novelista francesa.
"Alfredo Novoa" <alfred...@hotmail.com> wrote in message
news:evh2o21mokbasf568...@4ax.com...
> On Thu, 14 Dec 2006 11:05:29 +0100, "RFOG"
> <zephryn...@QUITAME.gmail.com> wrote:
>
>>Se está hablando por un lado de los "nullables", que personalmente, y como
>>tu, no entiendo su motivo ni por qué están
>
> Bueno, yo si lo entiendo y se por que están: por que en SQL hay nulos.
>
> Me parecen una guarrada, pero el culpable es SQL.
>
Vale.
>>, y por el otro el uso y la
>>posibilidad de asignar nulo a una variable, ¿no?
>
> Si.
>
>>Realmente el único sentido fuera del tema de acceso a datos, que
>>desconozco
>>casi completamente, de los "nullables" es el tener un valor más fuera del
>>dominio de la variable para que ésta pueda contener cualquiera de sus
>>posibles valores *más* el nulo, de este modo no tenemos que reservar un
>>posible valor para indicar "elemento no válido" o "elemento erróneo", o
>>como
>>queramos llamarlo.
>
> Ya, pero eso normalmente es otra chapuza. Eso se implementa mejor
> estructurando bien el código.
>
> Un tipo nullable es algo como esto:
>
> struct Nullable<T>
> {
> public bool HasValue;
> public T Value;
> }
>
> Pero además se meten en líos innecesarios con la lógica de tres
> valores y redefinen los operadores aritméticos y demás.
>
Era como lo imaginaba, con código oculto a porrilo, por lo que veo.
>>Respecto a los nulos dentro de una base de datos, si es lo que creo -no
>>tengo tiempo para mirarlo ahora-, creo, y sólo creo, que pudieran ser
>>útiles.
>
> La mayoría de los expertos en bases de datos piensan lo contrario.
> Tienes bastante información en los enlaces que he dejado.
>
>>Si un campo nulo o asignado a nulo es aquel que, una vez obtenido un
>>registro de una base de datos, no apunta a nada o no contiene nada, creo
>>que
>>tiene mucho sentido.
>
> En el Modelo Relacional no tienen ningún sentido. El Modelo Relacional
> es una aplicación directa de la lógica de predicados y la teoría de
> conjuntos. Si metes un nulo en una tabla entonces la tabla deja de
> representar a una relación matemática y esto produce una serie de
> consecuencias indeseables que están bien descritas en la literatura.
>
> En la práctica los nulos causan montones de bugs. Yo personalmente he
> tenido que corregir cientos de ellos, sin exagerar.
>
No te lo discuto, desde luego, visto desde el punto de lógica de predicados
y conjuntos, efectivamente, me suena un poco mal.
>>Imaginemos una base de datos con todos los españoes: 40 millones de
>>registros, con un campo memo con comentarios policiales. El 99,99% de los
>>españoles no tienen...
>>
>>Ahora imaginemos que ese campo debe contener un valor, que indice "vacío".
>
> ¿Que tal una cadena de texto de longitud cero?
>
Ti mismo respondes a eso abajo.
>>Si no recuerdo mal, son al menos 10 bytes para apuntar al memo. 10 x 40 x
>>10^6 bytes que nos ahorramos en la base de datos, sin contar con el propio
>>campo memo, que aunque esté vacío debe contener al menos un cero para
>>indicarlo (si no sería absurdo que algo apuntara a nada).
>
> Estás confundiendo el modelo lógico con el modelo físico. Hay muchas
> formas de implementar físicamente un modelo lógico. Un SGBD bien
> implementado podría hacer que un memo con un texto de longitud cero
> ocupase lo mismo que un nulo.
>
Cierto. Yo abandoné el tema de las bases de datos en la época del dbase III,
y recuerdo que el memo ocupaba 10 bytes en la tabla principal y 0 en donde
realmente se guardaban los memo si no ponías nada, de ahí mi ejemplo.
Evidentemente, ha llovido mucho desde eso.
>
> Saludos
Hernan
> >tu, no entiendo su motivo ni por qué están
>
> Bueno, yo si lo entiendo y se por que están: por que en SQL hay nulos.
> Me parecen una guarrada, pero el culpable es SQL.
Según la guía de referencia, una de las principales razones
de los "nullables" son las base de datos.
Lo raro es que ninguna de las clases de System.Data los aceptan
y hay que seguir con los DbNull.Value
Honestamente no se para qué se tomaron el trabajo de modificar el
lenguaje. Era suficiente agregar la clase generica Nullable<T>.
> En el Modelo Relacional no tienen ningún sentido. El Modelo Relacional
> es una aplicación directa de la lógica de predicados y la teoría de
> conjuntos. Si metes un nulo en una tabla entonces la tabla deja de
> representar a una relación matemática y esto produce una serie de
> consecuencias indeseables que están bien descritas en la literatura.
>
> En la práctica los nulos causan montones de bugs. Yo personalmente he
> tenido que corregir cientos de ellos, sin exagerar.
Ya es tarde. Hay que vivir con eso.
(Y vista la historia, dudo que cambie algo en los próximos 10 años)
-H.
Alfredo Novoa
On 14 Dec 2006 09:54:58 -0800, "Hernan" <hfof...@gmail.com> wrote:
>> En la práctica los nulos causan montones de bugs. Yo personalmente he
>> tenido que corregir cientos de ellos, sin exagerar.
>
>Ya es tarde. Hay que vivir con eso.
>(Y vista la historia, dudo que cambie algo en los próximos 10 años)
Estoy de acuerdo, pero no es tarde para usarlos lo menos posible.
Saludos
Juan Diego Bueno Prieto
pensar...
No ya en el uso o no, o el sentido de la existencia de los tipos nullable,
que nunca he tenido la necesidad de utilizar, sino en la utilización o no de
nulos.
Por una parte, me parece lógico el minimizar el uso de nulos en una BD ( a
mi me han dado más de un quebradero de cabeza), pero hay situaciones en las
que no veo como un SGBD podría resolver una situación sin su uso, por
ejemplo, en una vista que use una outer join de dos tablas en las que una de
ellas se relaciona solo opcionalmente con la otra.
Respecto a la forma de no usarlos, tanto en campos booleanos como numéricos
o de cadena, bastaría con unos valores por defecto (false, 0 o cadena
vacía), pero ¿qué pasa con las fechas?. A mi me duele en el alma poner como
fecha 1/1/1900, para eso prefiero dejarla nula. Si conoceis alguna
alternativa elegante, agradecería la sugerencia
Saludos
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:6lb3o25pfikvp08ie...@4ax.com...
--------------------------------------------------------------------------------
Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 11947 correos spam hasta la fecha.
Los abonados no tienen este mensaje en sus correos.
¡Pruebe SPAMfighter gratis ya!
Carlos M. Calvelo
Juan Diego Bueno Prieto schreef:
> Todo este tema, como siempre que sale algún debate de este tipo, me hace
> pensar...
> No ya en el uso o no, o el sentido de la existencia de los tipos nullable,
A mi me parecen un engorro del lenguage. Algo como los Variants en
Visual Basic. No solucionan nada y dan lugar a prácticas 'no muy
bien vistas', que en programas lo suficientemente complejos no
hacen mas que complicar las cosas.
> que nunca he tenido la necesidad de utilizar,
Eso es porque como bien dices arriba.. piensas! :)
> sino en la utilización o no de
> nulos.
>
> Por una parte, me parece lógico el minimizar el uso de nulos en una BD ( a
> mi me han dado más de un quebradero de cabeza), pero hay situaciones en las
> que no veo como un SGBD podría resolver una situación sin su uso, por
> ejemplo, en una vista que use una outer join de dos tablas en las que una de
> ellas se relaciona solo opcionalmente con la otra.
¿Conoces este artículo?
http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf
En cuanto a los outer joins hay que realizarse que en realidad
son equivalentes a un join y una unión. Por ejemplo:
select t1.a, t2.b from t1 left outer join t2 on t1.id=t2.id
es equivalente a
select t1.a, t2.b from t1 inner join t2 on t1.id=t2.id
union
select t1.a, null from t1 where t1.id not in (select id from t2)
Para ver la diferencia se podría hacer por ejemplo:
select 1, t1.a, t2.b from t1 inner join t2 on t1.id=t2.id
union
select 0, t1.a, '?' from t1 where t1.id not in (select id from t2)
ó quizás mejor:
select case when t2.id is null then 0 else 1 end,
t1.a,t2.b
from t1 left outer join t2 on t1.id=t2.id
Filas con un 1 en el primer atributo tienen valores en las
columnas de t2 y filas con 0 no. Otra opción sería tratar los dos
selects de la unión por separado pero eso tendría que ser dentro
de la misma transación para garantizar el mismo resultado que un
outer join. No sé si esto es *la solución* pero pensando...
pensando... vienen las ideas. En todo caso evita la lógica
de tres valores al no hacerle caso a los null.
>
> Respecto a la forma de no usarlos, tanto en campos booleanos como numéricos
> o de cadena, bastaría con unos valores por defecto (false, 0 o cadena
> vacía), pero ¿qué pasa con las fechas?. A mi me duele en el alma poner como
> fecha 1/1/1900, para eso prefiero dejarla nula. Si conoceis alguna
> alternativa elegante, agradecería la sugerencia
Espero que el artículo que mencioné arriba te dé ideas si es que
no lo conocías ya. Pero de todas formas el tema del 'missing
information', que yo sepa, aún no está solucionado
satisfactoriamente.
Saludos,
Carlos
Alfredo Novoa
<jua...@mow.jazztel.es> wrote:
>Por una parte, me parece lógico el minimizar el uso de nulos en una BD ( a
>mi me han dado más de un quebradero de cabeza), pero hay situaciones en las
>que no veo como un SGBD podría resolver una situación sin su uso, por
>ejemplo, en una vista que use una outer join de dos tablas en las que una de
>ellas se relaciona solo opcionalmente con la otra.
Es fácil. Solo habría que especificar un valor de relleno. En SQL se
puede hacer usando COALESCE().
Es muy recomendable usar COALESCE con "outer joins" para que el
resultado no tenga nulos, sobre todo en el caso de columnas numéricas.
>Respecto a la forma de no usarlos, tanto en campos booleanos como numéricos
>o de cadena, bastaría con unos valores por defecto (false, 0 o cadena
>vacía), pero ¿qué pasa con las fechas?. A mi me duele en el alma poner como
>fecha 1/1/1900, para eso prefiero dejarla nula. Si conoceis alguna
>alternativa elegante, agradecería la sugerencia
La solución elegante es partir la tabla en vertical.
Ejemplo:
Cliente Nombre Fecha Nacimiento
-------- ---------- ---------------------
1 Pepe 6/9/1969
2 Paco null
Sin nulos sería:
Cliente Nombre
-------- ----------
1 Pepe
2 Paco
Cliente Fecha Nacimiento
-------- ---------------------
1 6/9/1969
Lo malo es que con los SGBD actuales esto puede dar problemas de
rendimiento (aunque hay trucos para evitarlo), y puede ser incómodo de
manejar. Pero la culpa la tiene lo inflexibles que son los SGBD
actuales.
En la práctica a veces no queda más remedio que usar nulos como mal
menor debido a las limitaciones de la tecnología actual.
Saludos
Alfredo
Juan Diego Bueno Prieto
Primeramente, puntualizar que la situación con los outer join ya la tenía
resuelta, precisamente con una de las opciones que plantea Carlos, aparte de
con el uso de la función ISNULL de T-SQL, y había leído algo sobre
COALESCE(). Me refería más bien a como se plantearía esta situación en un
SQL sin la posibilidad de nulos.
Carlos, el documento este tiene muy buena pinta, lo leeré con calma.
Por otra parte, respecto a las fechas, la solución de usar otra tabla me
parece elegante, máxime en mi caso que procuro que exista la menor
redundancia posible en mis BDs, aunque creo que salvo para casos
excepcionales, seguiré usando campos nulos con las fechas. De hecho, ahora
recuerdo como heredé una base de datos de un compañero que usaba un
criterio parecido desglosando una tabla en aproximadamente 15 diferentes y
se hacía harto complicado construir las consultas e informes.
Como os decía, gracias por las aportaciones
Saludos
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:m075o2h1q3vrj36ia...@4ax.com...
--------------------------------------------------------------------------------
Estoy utilizando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 12027 correos spam hasta la fecha.
Carlos M. Calvelo
Juan Diego Bueno Prieto schreef:
> Primeramente, puntualizar que la situación con los outer join ya la tenía
> resuelta, precisamente con una de las opciones que plantea Carlos, aparte de
> con el uso de la función ISNULL de T-SQL, y había leído algo sobre
> COALESCE(). Me refería más bien a como se plantearía esta situación en un
> SQL sin la posibilidad de nulos.
Con SQL vamos a tener nulos para rato, me temo. Y creo que aunque
la industria acepte un lenguage realmente relacional aparecerán
productos
en los que no podrán resistir la tentación de implementar nulos.
Lo que si podemos es tratar de evitar 'infectar' las aplicaciones con
el mismo tipo de lógica.
>
> Carlos, el documento este tiene muy buena pinta, lo leeré con calma.
>
> Por otra parte, respecto a las fechas, la solución de usar otra tabla me
> parece elegante, máxime en mi caso que procuro que exista la menor
> redundancia posible en mis BDs, aunque creo que salvo para casos
> excepcionales, seguiré usando campos nulos con las fechas. De hecho, ahora
> recuerdo como heredé una base de datos de un compañero que usaba un
> criterio parecido desglosando una tabla en aproximadamente 15 diferentes y
> se hacía harto complicado construir las consultas e informes.
Dado este ejemplo creo que vas a reconocer bastante en el documento.
Pero los SGBD's actuales no se han orientado hacia este tipo de
soluciones y han escogido la opción de los nulos. Por eso los SGBD's
no ayudan precisamente a hacer las cosas bien. No deja de ser
interesante leer el documento porque si se puede diseñar tratando
de evitar nulos al máximo, dentro de lo practicamente posible.
Saludos,
Carlos
JC
opinion (como en todo) hay casos en q se deben utilizar (claro sin abusar)
un ejemplo:
Supongan q tienen que llenar una listas de objetos "Contactos" con muchos
campos de tipo string (FirstName, LastName...etc, etc). Como el caso de una
lista de contactos como los del outlook...Cada contacto tiene como 100
campos en su mayoria string.
Las cadenas (string) son "pesadas" y consumen muchos recursos. Puede ser
mejor dejar estos campos (Pienso en el constructor ) sin inicializar (o sea
en null) q asignarle "". Luego se puede verificar si es null lo mismo q
verificar si esta asignada a "". Puede ser mas rapido incluso verificar si
es un null q si es "".)
Si usted asigna todos los campos string null a "", en una lista con 300
contactos por poner un numero tendra una carga considerable en esta funcion
en comparacion con si los dejas en null
"pepito" <pep...@pepito.com> wrote in message
news:uszz7Hk...@TK2MSFTNGP02.phx.gbl...
Hola compañeros....
¿Es imposible en .NET a un valor entero o booleano asignarle un valor nulo
que permita diferenciar el valor 0 o false respectivamente?
Gracias...
Alfredo Novoa
wrote:
>Los nulos como todo lo q crea (o modela) el hombre estan por algo.
Si, claro. Por error.
>Las cadenas (string) son "pesadas" y consumen muchos recursos.
No tienen por que serlo.
> Puede ser mas rapido incluso verificar si
>es un null q si es "".)
Y puede no serlo. No debería de haber diferencias significativas.
>Si usted asigna todos los campos string null a "", en una lista con 300
>contactos por poner un numero tendra una carga considerable en esta funcion
>en comparacion con si los dejas en null
No tiene por que tardar más una cosa que la otra.
Saludos
JC
>
> Si, claro. Por error.
>>Las cadenas (string) son "pesadas" y consumen muchos recursos.
>
> No tienen por que serlo.
>> Puede ser mas rapido incluso verificar si
>>es un null q si es "".)
>
> Y puede no serlo. No debería de haber diferencias significativas.
Puedo estar de acuerdo.
>>Si usted asigna todos los campos string null a "", en una lista con 300
>>contactos por poner un numero tendra una carga considerable en esta
>>funcion
>>en comparacion con si los dejas en null
>
> No tiene por que tardar más una cosa que la otra.
Pienso q cuando se instancia el objeto por defecto todos sus campos objetos
ya estan en null.
No considero q sea una buena practica, sin embargo en casos como el del
ejemplo, puede ser una opcion en lugar de instanciar un gran numero de
string con "" dejarlos en null.
O sea, en el primer caso dejo las cosas como estan al "principio" y
"termino", en el segundo despues de este "principio" voy campo a campo del
objeto haciendo UnString = "" lo q introduce cierta demora. Si el numero de
estos string es grande, digamos unos 100-200, y es una tarea q se repitara
mucho, (unas 100-200 veces) como el ejemplo de llenado de una lista creo q
es mejor deajarlos en null. Sobre todo si esto no tendra mayores
consecuencias en el programa o se resuelven estas de un modo inteligente.
En terminos generales estoy de acuerdo en evitar los nulos. Pero como dijo
alguien "En programacion no hay balas de plata". Cada solucion hay q
revisarla en particular.
Gracias a ti.
> Saludos
Alfredo Novoa
wrote:
>>>Los nulos como todo lo q crea (o modela) el hombre estan por algo.
>>
>> Si, claro. Por error.
>No estoy de acuerdo con tu opinion. Creo q es demasiado rigida.
Será todo lo rígida que quieras pero es así. Los nulos corrompen
completamente los fundamentos de Modelo Relacional y los problemas
prácticos son más que conocidos.
>> No tiene por que tardar más una cosa que la otra.
>Pienso q cuando se instancia el objeto por defecto todos sus campos objetos
>ya estan en null.
Estamos hablando de tablas, no de objetos.
Si pones un default "" en un campo, entonces se inicia con una cadena
vacía por defecto y no tendría por que tardar más que con un nulo.
Los nulos de los objetos no tienen nada que ver con los nulos de las
tablas. Un nulo en una tabla significa que el atributo no tiene ningún
valor. Un nulo en un objeto es un puntero que apunta a una dirección
que por convención se usa para decir que no apunta a ningún sitio. En
este último caso un nulo si es un valor y en el otro es una marca para
decir que estamos haciendo una chapuza.
>En terminos generales estoy de acuerdo en evitar los nulos. Pero como dijo
>alguien "En programacion no hay balas de plata".
Si las hay, y bastantes.
Saludos
Alfredo
Vyacheslav Popov
me pregunto si ¿existe algún lenguaje de programación, además de SQL (por
nombrar alguno aunque no sea de programación), que se adapta a tus
convenciones?
Saludos.
"Alfredo Novoa" <alfred...@hotmail.com> escribió en el mensaje
news:2gt9q296u76enp5vf...@4ax.com...
Carlos M. Calvelo
Vyacheslav Popov schreef:
> Feliz año Alfredo,
> me pregunto si ¿existe algún lenguaje de programación, además de SQL (por
> nombrar alguno aunque no sea de programación), que se adapta a tus
> convenciones?
>
Feliz año!
Yo también me pregunto:
¿Por qué crees que SQL se adapta a sus convenciones?
¿Qué aplicación tienes para la lógica de tres valores? (que
de nulos se está hablando) of por preguntarlo de otra manera,
¿Se adapta esta lógica a tus convenciones?
Saludos,
Carlos
Alfredo Novoa
<popov-quit...@binslon.com> wrote:
¡Feliz año Vyacheslav!
>me pregunto si ¿existe algún lenguaje de programación, además de SQL (por
>nombrar alguno aunque no sea de programación), que se adapta a tus
>convenciones?
SQL no se adapta para nada entre otras muchas cosas por que tiene
nulos, pero si es un lenguaje de programación.
No hay ningun lenguaje que me satisfaga totalmente (si fuese así
estaría preocupado, por que todo se puede mejorar :).
Pero ya que lo preguntas, el lenguaje que más me gusta es Tutorial D.
Aunque no es realmente un lenguaje, sino que es una especie de esbozo
para crear otros lenguajes reales. Yo estoy creando el mio, pero no
tengo mucho tiempo para esto, aunque algunas cosas ya compilan y
funcionan :-)
Tutorial D está pensado para ser el lenguaje de un DBMS, pero también
podría utilizarse como lenguaje de programación de propósito general
añadiendole algunas cosillas (por ejemplo Darwen propuso una sintaxis
muy interesante para los genéricos). Tutorial D corrige los defectos
más conocidos de la mayoría de los lenguajes OO.
Saludos
Alfredo
Vyacheslav Popov
> nulos, pero si es un lenguaje de programación.
Tendré que creerte ;)
> Pero ya que lo preguntas, el lenguaje que más me gusta es Tutorial D.
> Aunque no es realmente un lenguaje, sino que es una especie de esbozo
> para crear otros lenguajes reales. Yo estoy creando el mio, pero no
> tengo mucho tiempo para esto, aunque algunas cosas ya compilan y
> funcionan :-)
¡Animo Alfredo! a ver si haces algo más "decente"
Saludos.
JC
jejejeje...quizas ni siquiera objetos!!!
Gracias!
Hola compañeros....
¿Es imposible en .NET a un valor entero o booleano asignarle un valor nulo
que permita diferenciar el valor 0 o false respectivamente?
Gracias...
"Alfredo Novoa" <alfred...@hotmail.com> wrote in message
news:2gt9q296u76enp5vf...@4ax.com...
Alfredo Novoa
wrote:
>El mensaje q inicio la discusion no menciona para nada tablas...
>jejejeje...quizas ni siquiera objetos!!!
Con objetos nunca puedes estar seguro de nada, por que no hay una
definición precisa de lo que es un objeto y un objeto puede ser
cualquier cosa. Es una palabra que habría que erradicar de la
informática.
Saludos
Alfredo