SQL SERVER fecha 01/Ene/1900

Si tengo que dar de baja , para no tener redundancia en todos los registros
de mi inventario, donde seguramente el indice de bajas es muy bajo, guardo
en tabla aparte de BAJAS, código de artículo y fecha de baja, dónde nunca
estará VACIA.
= Normalización.

Salu2.
Nelson


"Esparta Palma" escribió en el
mensaje news:%23$
Mostrar la cita

Desaconsejable?
Yo no diría eso, hay casos muy específicos en dónde es necesario, y
cualquier "consejo" lo tienes que tirar por la borda, por ejemplo, si
guardas la fecha en que das de baja un item de tu inventario, que fecha le
pones si tu item sigue en uso??, la fecha de hoy?, la fecha de un
aproximado?, pues no, le pones NULL!!

El concepto de NULL es algo muy interesante, ha formado una revolución en
los conceptos de base de datos, ya que un valor NULL tiene la capacidad de
ser nada y a la vez significar algo, algo muy parecido a lo ocurrido con
la invención del número cero (cortesía de los pueblos Mayas) .

El concepto de NULL ayuda bastante a darse cuenta de lo que no se conoce,
y generalmente responde a todas las preguntas con un "No lo sé":

1.- ¿En que fecha te moriste? --> NULL --> No lo sé, sigo vivo.
2.- ¿Cuantos años tenias cuando te divorciaste? --> NULL -> No lo sé,
nisiquiera me he casado
3.- ¿Cuanto dinero ganas con tu jubilación? --> NULL --> No lo sé, no me
he jubilado, sigo trabajando

Así pues, considero que *no* es "desaconsejable" el uso de NULLs, en otras
palabras, lo debe usar sólo en los casos en que no se sabe con certeza las
cosas, que de casos hay muchos. Por otro lado, quizás sea incómodo su uso
(para aquellos que inician en éstos conceptos), pero de que sea
desaconsejable, de ninguna manera, es más bien cuestión de acostumbrarse,
como dirían otros:"Es como ir a un picnic y no encontrar hormigas"

Claro está que en algunos casos le puedes poner algo que según TU modo de
ver signifique "algo", por ejemplo, si la fecha de nacimiento y defunción
es la misma y una banderita de finado *no* está puesta, entonces no sabes;
o si le pones cero en los años de divorciado, entonces no se ha
divorciado; o si le pones $0 a la cantidad ganada en tu jubilación... ahhh
entonces NO está jubilado. Si, es fácil, es sencillo, pero incurres en
graves problemas debido a que estás falseando una información y se cae en
ambiguedades relativas a interpretaciones personales, ya que desde un
inicio, lo que quisiste decir fué "No lo sé", para qué complicarse la vida
?, si no lo sabes, dilo, pero no inventes. Las bases de datos deben ser
confiables y no presentar inconherencias nunca.

Saludos!


>De todas maneras ten en cuenta que altamente desaconsejable dejar campos
>con valor NULL dentro de las tablas SQL Server ya que si participan

alguna
Mostrar la cita

>vez en consultas SELECT los resultados son impredecibles, a no ser,

claro,
Mostrar la cita

>que los tengas en cuenta y escribas las SELECT para no considerar.
>Salu2

>Nelson Rodriguez
>Salto - Uruguay
>

"Alberto Muñoz" escribió en el mensaje
news:eX$
> Hola Grupo.
>
> Hay alguna forma de evitar que se grabe en la tabla la fecha 01/Ene/1900
> cuando el usuario deja vacio el campo de fecha y oprime el botón grabar

en
Mostrar la cita

> la aplicación?
>
> Es posible dejar el campo fecha vacío sin que se grabe esta fecha?
>
> Gracias por cualquier ayuda.

¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway

La práctica es lo que se establece en la realidad, siempre y cuándo se
adapte a la suya propia, no pretendo ingorar, sino tomar en cuenta, yo lo
leí, lo probé, implementé y hasta la fecha no se han presentado
"chorizos", y como bien dice, aumenta la complejidad, más no que se
obtendrían datos erroneos, recomiendan en ese libro utilizar los valores
por default en cualquier lugar que fuere necesario, pero siempre, y eso es
siempre dependerá del caso específico.

La ignorancia no necesariamente lleva a errores, sino a no-resolución de
conflictos, así pues, en ese y toda la bibliografía que encuentres te dirá
que debes evitarlo o en caso contrario (si decide llevarlo a cabo) tomar
las consideraciones pertinentes como se lleva en el uso de las funciones
ISNULL. De otra manera si fuera tan malo, sería removido de SQLServer y de
todos los demás servidores de bases de datos.

Entonces, nos estamos enfrentando a una interpretación de lo que dicen en
bibliografías, caso similar a la interpretación de la biblia. Llamado por
los anglosajones: "Holly War".

Cito una vez más a Fernando Guerrero.
***********************************************
*From: Fernando G. Guerrero ()
*Subject: Re: Recomendación de Fechas vacías
*Newsgroups: microsoft.public.es.sqlserver
*Date: 2001-12-10 01:42:48 PST
***********************************************

SQL Server 2000 almacena un mapa de bits en cada registro para indicar qué
campos son nulos, y su acceso mediante IS NULL es muy eficiente.

Conceptualmente, los valores desconocidos deberían representarse mediante
NULL, ya que la utilización de valores por defecto que representen valores
desconocidos podrían dar algunos problemas en el futuro (todos recordamos
los problemas por la utilización de 9/9/99 como fecha nula).

Los valores NULL son considerados también en la creación de índices, y las
consultas que incluyen IS NULL pueden utilizar el índice del mismo modo que
cualquier otro valor.

<SNIP>
************** Fin de Cita *************************

Asi pues, tu interpretación no debería ser sobre total rechazo, sino de
revisión a diferentes casos de uso. Eso que comenta Guerrero se lo
pregunté personalmente, e hicimos una gran extensión del concepto junto
con su implementación en SQLServer (dónde él es un maestro).



Mostrar la cita

De la teoría debemos bajar a la práctica, o sea implementar. Si implemento
en SQL Server , debo evitar NULLs, o complicarme en las consultas.
Si implemento en Oracle, tendré otros problemas, y así sucesivamente. Si
IGNORO los consejos bibliográficos, seguramentes las consultas me devolveran
"chorizos" y chocaré como buen ignorante con los mismos errores que ya otros
chocaron.
Solo pretendía evitarle (transmitiendo consejos de gente que sabe mucho) a
Alberto Muñoz dolores de cabeza.

Salu2
Nelson

"Esparta Palma" escribió en el
mensaje news:O3Slj$
Mostrar la cita

Ese libro lo tengo, y platiqué en persona con Guerrero sobre eso y otras
cosas, y que sea un excelente no me quita la idea de que si no SQLServer
no es el único servidor en el mundo, si se aumenta la complejidad, pues es
problema de SQLServer. De lo que yo hablo y nunca mencioné proovedores es
teoría pura de base de datos, la cual los fabricantes deberían implementar
sin aumentar complejidad.

>Otra bibliografía:
>"Programación en Microsoft SQL Server 2000" Con ejemplos, de Guerrero y
>Carlos Eduardo Rojas. Página 139 se puede apreciar lo que significa
>complejidad en el otro libro citado, referido a la contemplación de los
>valores NULL en los campos que participan en la cláusula WHERE.
>Salu2
>Nelson

"Esparta Palma" escribió en el
mensaje news:%23$
> Desaconsejable?
> Yo no diría eso, hay casos muy específicos en dónde es necesario, y
> cualquier "consejo" lo tienes que tirar por la borda, por ejemplo, si
> guardas la fecha en que das de baja un item de tu inventario, que fecha

le
Mostrar la cita

> pones si tu item sigue en uso??, la fecha de hoy?, la fecha de un
> aproximado?, pues no, le pones NULL!!
>
> El concepto de NULL es algo muy interesante, ha formado una revolución

en
Mostrar la cita

> los conceptos de base de datos, ya que un valor NULL tiene la capacidad

de
Mostrar la cita

> ser nada y a la vez significar algo, algo muy parecido a lo ocurrido con
> la invención del número cero (cortesía de los pueblos Mayas) .
>
> El concepto de NULL ayuda bastante a darse cuenta de lo que no se

conoce,
Mostrar la cita

> y generalmente responde a todas las preguntas con un "No lo sé":
>
> 1.- ¿En que fecha te moriste? --> NULL --> No lo sé, sigo vivo.
> 2.- ¿Cuantos años tenias cuando te divorciaste? --> NULL -> No lo sé,
> nisiquiera me he casado
> 3.- ¿Cuanto dinero ganas con tu jubilación? --> NULL --> No lo sé, no me
> he jubilado, sigo trabajando
>
> Así pues, considero que *no* es "desaconsejable" el uso de NULLs, en

otras
Mostrar la cita

> palabras, lo debe usar sólo en los casos en que no se sabe con certeza

las
Mostrar la cita

> cosas, que de casos hay muchos. Por otro lado, quizás sea incómodo su

uso
Mostrar la cita

> (para aquellos que inician en éstos conceptos), pero de que sea
> desaconsejable, de ninguna manera, es más bien cuestión de

acostumbrarse,
Mostrar la cita

> como dirían otros:"Es como ir a un picnic y no encontrar hormigas"
>
> Claro está que en algunos casos le puedes poner algo que según TU modo

de
Mostrar la cita

> ver signifique "algo", por ejemplo, si la fecha de nacimiento y

defunción
Mostrar la cita

> es la misma y una banderita de finado *no* está puesta, entonces no

sabes;
Mostrar la cita

> o si le pones cero en los años de divorciado, entonces no se ha
> divorciado; o si le pones $0 a la cantidad ganada en tu jubilación...

ahhh
Mostrar la cita

> entonces NO está jubilado. Si, es fácil, es sencillo, pero incurres en
> graves problemas debido a que estás falseando una información y se cae

en
Mostrar la cita

> ambiguedades relativas a interpretaciones personales, ya que desde un
> inicio, lo que quisiste decir fué "No lo sé", para qué complicarse la

vida
Mostrar la cita

> ?, si no lo sabes, dilo, pero no inventes. Las bases de datos deben ser
> confiables y no presentar inconherencias nunca.
>
> Saludos!
>
>
> >De todas maneras ten en cuenta que altamente desaconsejable dejar

campos
Mostrar la cita

> >con valor NULL dentro de las tablas SQL Server ya que si participan
alguna
> >vez en consultas SELECT los resultados son impredecibles, a no ser,
claro,
> >que los tengas en cuenta y escribas las SELECT para no considerar.
> >Salu2
>
> >Nelson Rodriguez
> >Salto - Uruguay
> >
>
> "Alberto Muñoz" escribió en el mensaje
> news:eX$
> > Hola Grupo.
> >
> > Hay alguna forma de evitar que se grabe en la tabla la fecha

01/Ene/1900
Mostrar la cita

> > cuando el usuario deja vacio el campo de fecha y oprime el botón

grabar
Mostrar la cita

en
> > la aplicación?
> >
> > Es posible dejar el campo fecha vacío sin que se grabe esta fecha?
> >
> > Gracias por cualquier ayuda.

ž,ø€º°`°º€ø,žž,ø€º°`°º€ø,žž,ø€º°`°º€ø,žž,ø€º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway

De la teoría debemos bajar a la práctica, o sea implementar. Si implemento
en SQL Server , debo evitar NULLs, o complicarme en las consultas.
Si implemento en Oracle, tendré otros problemas, y así sucesivamente. Si
IGNORO los consejos bibliográficos, seguramentes las consultas me devolveran
"chorizos" y chocaré como buen ignorante con los mismos errores que ya otros
chocaron.
Solo pretendía evitarle (transmitiendo consejos de gente que sabe mucho) a
Alberto Muñoz dolores de cabeza.

Salu2
Nelson

"Esparta Palma" escribió en el
mensaje news:O3Slj$
Mostrar la cita

Ese libro lo tengo, y platiqué en persona con Guerrero sobre eso y otras
cosas, y que sea un excelente no me quita la idea de que si no SQLServer
no es el único servidor en el mundo, si se aumenta la complejidad, pues es
problema de SQLServer. De lo que yo hablo y nunca mencioné proovedores es
teoría pura de base de datos, la cual los fabricantes deberían implementar
sin aumentar complejidad.

>Otra bibliografía:
>"Programación en Microsoft SQL Server 2000" Con ejemplos, de Guerrero y
>Carlos Eduardo Rojas. Página 139 se puede apreciar lo que significa
>complejidad en el otro libro citado, referido a la contemplación de los
>valores NULL en los campos que participan en la cláusula WHERE.
>Salu2
>Nelson

"Esparta Palma" escribió en el
mensaje news:%23$
> Desaconsejable?
> Yo no diría eso, hay casos muy específicos en dónde es necesario, y
> cualquier "consejo" lo tienes que tirar por la borda, por ejemplo, si
> guardas la fecha en que das de baja un item de tu inventario, que fecha

le
Mostrar la cita

> pones si tu item sigue en uso??, la fecha de hoy?, la fecha de un
> aproximado?, pues no, le pones NULL!!
>
> El concepto de NULL es algo muy interesante, ha formado una revolución

en
Mostrar la cita

> los conceptos de base de datos, ya que un valor NULL tiene la capacidad

de
Mostrar la cita

> ser nada y a la vez significar algo, algo muy parecido a lo ocurrido con
> la invención del número cero (cortesía de los pueblos Mayas) .
>
> El concepto de NULL ayuda bastante a darse cuenta de lo que no se

conoce,
Mostrar la cita

> y generalmente responde a todas las preguntas con un "No lo sé":
>
> 1.- ¿En que fecha te moriste? --> NULL --> No lo sé, sigo vivo.
> 2.- ¿Cuantos años tenias cuando te divorciaste? --> NULL -> No lo sé,
> nisiquiera me he casado
> 3.- ¿Cuanto dinero ganas con tu jubilación? --> NULL --> No lo sé, no me
> he jubilado, sigo trabajando
>
> Así pues, considero que *no* es "desaconsejable" el uso de NULLs, en

otras
Mostrar la cita

> palabras, lo debe usar sólo en los casos en que no se sabe con certeza

las
Mostrar la cita

> cosas, que de casos hay muchos. Por otro lado, quizás sea incómodo su

uso
Mostrar la cita

> (para aquellos que inician en éstos conceptos), pero de que sea
> desaconsejable, de ninguna manera, es más bien cuestión de

acostumbrarse,
Mostrar la cita

> como dirían otros:"Es como ir a un picnic y no encontrar hormigas"
>
> Claro está que en algunos casos le puedes poner algo que según TU modo

de
Mostrar la cita

> ver signifique "algo", por ejemplo, si la fecha de nacimiento y

defunción
Mostrar la cita

> es la misma y una banderita de finado *no* está puesta, entonces no

sabes;
Mostrar la cita

> o si le pones cero en los años de divorciado, entonces no se ha
> divorciado; o si le pones $0 a la cantidad ganada en tu jubilación...

ahhh
Mostrar la cita

> entonces NO está jubilado. Si, es fácil, es sencillo, pero incurres en
> graves problemas debido a que estás falseando una información y se cae

en
Mostrar la cita

> ambiguedades relativas a interpretaciones personales, ya que desde un
> inicio, lo que quisiste decir fué "No lo sé", para qué complicarse la

vida
Mostrar la cita

> ?, si no lo sabes, dilo, pero no inventes. Las bases de datos deben ser
> confiables y no presentar inconherencias nunca.
>
> Saludos!
>
>
> >De todas maneras ten en cuenta que altamente desaconsejable dejar

campos
Mostrar la cita

> >con valor NULL dentro de las tablas SQL Server ya que si participan
alguna
> >vez en consultas SELECT los resultados son impredecibles, a no ser,
claro,
> >que los tengas en cuenta y escribas las SELECT para no considerar.
> >Salu2
>
> >Nelson Rodriguez
> >Salto - Uruguay
> >
>
> "Alberto Muñoz" escribió en el mensaje
> news:eX$
> > Hola Grupo.
> >
> > Hay alguna forma de evitar que se grabe en la tabla la fecha

01/Ene/1900
Mostrar la cita

> > cuando el usuario deja vacio el campo de fecha y oprime el botón

grabar
Mostrar la cita

en
> > la aplicación?
> >
> > Es posible dejar el campo fecha vacío sin que se grabe esta fecha?
> >
> > Gracias por cualquier ayuda.

¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway

Por supuesto, interpreté en "el aire" un caso, tu propusistes otro diferente
del interpretado Pero no es el tema. Hay tantas "lógicas" como se nos pueda
ocurrir.
Salu2
Nelson

"Esparta Palma" escribió en el
mensaje news:
Mostrar la cita

Lo vas a dar de baja en tu entidad baja, pero todavía no averiguas que
fecha fué? Le pones 01/01/1990?, tampoco indiqué implementación de proceso
de bajas y de hecho nunca pensaba en tener una entidad items con un campo
de fecha de baja ;) . Si me dices que esperarás a que sepan la fecha, lo
dudo... Si me dices que la fecha de hoy y que después la cambien? Fácil
manera de falsear datos, por que te arriesgas a que se le olvide a quien
lo está dando de baja.

>Si tengo que dar de baja , para no tener redundancia en todos los

registros
Mostrar la cita

>de mi inventario, donde seguramente el indice de bajas es muy bajo,

guardo
Mostrar la cita

>en tabla aparte de BAJAS, código de artículo y fecha de baja, dónde nunca
>estará VACIA.
>= Normalización.

>Salu2.
>Nelson


"Esparta Palma" escribió en el
mensaje news:%23$
> Desaconsejable?
> Yo no diría eso, hay casos muy específicos en dónde es necesario, y
> cualquier "consejo" lo tienes que tirar por la borda, por ejemplo, si
> guardas la fecha en que das de baja un item de tu inventario, que fecha

le
Mostrar la cita

> pones si tu item sigue en uso??, la fecha de hoy?, la fecha de un
> aproximado?, pues no, le pones NULL!!
>
> El concepto de NULL es algo muy interesante, ha formado una revolución

en
Mostrar la cita

> los conceptos de base de datos, ya que un valor NULL tiene la capacidad

de
Mostrar la cita

> ser nada y a la vez significar algo, algo muy parecido a lo ocurrido con
> la invención del número cero (cortesía de los pueblos Mayas) .
>
> El concepto de NULL ayuda bastante a darse cuenta de lo que no se

conoce,
Mostrar la cita

> y generalmente responde a todas las preguntas con un "No lo sé":
>
> 1.- ¿En que fecha te moriste? --> NULL --> No lo sé, sigo vivo.
> 2.- ¿Cuantos años tenias cuando te divorciaste? --> NULL -> No lo sé,
> nisiquiera me he casado
> 3.- ¿Cuanto dinero ganas con tu jubilación? --> NULL --> No lo sé, no me
> he jubilado, sigo trabajando
>
> Así pues, considero que *no* es "desaconsejable" el uso de NULLs, en

otras
Mostrar la cita

> palabras, lo debe usar sólo en los casos en que no se sabe con certeza

las
Mostrar la cita

> cosas, que de casos hay muchos. Por otro lado, quizás sea incómodo su

uso
Mostrar la cita

> (para aquellos que inician en éstos conceptos), pero de que sea
> desaconsejable, de ninguna manera, es más bien cuestión de

acostumbrarse,
Mostrar la cita

> como dirían otros:"Es como ir a un picnic y no encontrar hormigas"
>
> Claro está que en algunos casos le puedes poner algo que según TU modo

de
Mostrar la cita

> ver signifique "algo", por ejemplo, si la fecha de nacimiento y

defunción
Mostrar la cita

> es la misma y una banderita de finado *no* está puesta, entonces no

sabes;
Mostrar la cita

> o si le pones cero en los años de divorciado, entonces no se ha
> divorciado; o si le pones $0 a la cantidad ganada en tu jubilación...

ahhh
Mostrar la cita

> entonces NO está jubilado. Si, es fácil, es sencillo, pero incurres en
> graves problemas debido a que estás falseando una información y se cae

en
Mostrar la cita

> ambiguedades relativas a interpretaciones personales, ya que desde un
> inicio, lo que quisiste decir fué "No lo sé", para qué complicarse la

vida
Mostrar la cita

> ?, si no lo sabes, dilo, pero no inventes. Las bases de datos deben ser
> confiables y no presentar inconherencias nunca.
>
> Saludos!
>
>
> >De todas maneras ten en cuenta que altamente desaconsejable dejar

campos
Mostrar la cita

> >con valor NULL dentro de las tablas SQL Server ya que si participan
alguna
> >vez en consultas SELECT los resultados son impredecibles, a no ser,
claro,
> >que los tengas en cuenta y escribas las SELECT para no considerar.
> >Salu2
>
> >Nelson Rodriguez
> >Salto - Uruguay
> >
>
> "Alberto Muñoz" escribió en el mensaje
> news:eX$
> > Hola Grupo.
> >
> > Hay alguna forma de evitar que se grabe en la tabla la fecha

01/Ene/1900
Mostrar la cita

> > cuando el usuario deja vacio el campo de fecha y oprime el botón

grabar
Mostrar la cita

en
> > la aplicación?
> >
> > Es posible dejar el campo fecha vacío sin que se grabe esta fecha?
> >
> > Gracias por cualquier ayuda.

¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway

Evidentemente no pensamos igual , por suerte.
Pero repito lo del principio:
"De todas maneras ten en cuenta que es altamente desaconsejable dejar campos
con valor NULL dentro de las tablas SQL Server".

Consejo recibido (y leído) y consejo dado. Y por lo que veo también has
aceptado consejos de bibliografía, sino no los leerías. Bienvenido. Eso es
bueno, pensar que a veces no lo sabemos todo.
Cómo dijera Socrátes:
"Yo solo sé que no sé nada".
Salu2
Nelson


"Esparta Palma" escribió en el
mensaje news:
Mostrar la cita

La práctica es lo que se establece en la realidad, siempre y cuándo se
adapte a la suya propia, no pretendo ingorar, sino tomar en cuenta, yo lo
leí, lo probé, implementé y hasta la fecha no se han presentado
"chorizos", y como bien dice, aumenta la complejidad, más no que se
obtendrían datos erroneos, recomiendan en ese libro utilizar los valores
por default en cualquier lugar que fuere necesario, pero siempre, y eso es
siempre dependerá del caso específico.

La ignorancia no necesariamente lleva a errores, sino a no-resolución de
conflictos, así pues, en ese y toda la bibliografía que encuentres te dirá
que debes evitarlo o en caso contrario (si decide llevarlo a cabo) tomar
las consideraciones pertinentes como se lleva en el uso de las funciones
ISNULL. De otra manera si fuera tan malo, sería removido de SQLServer y de
todos los demás servidores de bases de datos.

Entonces, nos estamos enfrentando a una interpretación de lo que dicen en
bibliografías, caso similar a la interpretación de la biblia. Llamado por
los anglosajones: "Holly War".

Cito una vez más a Fernando Guerrero.
***********************************************
*From: Fernando G. Guerrero ()
*Subject: Re: Recomendación de Fechas vacías
*Newsgroups: microsoft.public.es.sqlserver
*Date: 2001-12-10 01:42:48 PST
***********************************************

SQL Server 2000 almacena un mapa de bits en cada registro para indicar qué
campos son nulos, y su acceso mediante IS NULL es muy eficiente.

Conceptualmente, los valores desconocidos deberían representarse mediante
NULL, ya que la utilización de valores por defecto que representen valores
desconocidos podrían dar algunos problemas en el futuro (todos recordamos
los problemas por la utilización de 9/9/99 como fecha nula).

Los valores NULL son considerados también en la creación de índices, y las
consultas que incluyen IS NULL pueden utilizar el índice del mismo modo

que
Mostrar la cita

cualquier otro valor.

<SNIP>
************** Fin de Cita *************************

Asi pues, tu interpretación no debería ser sobre total rechazo, sino de
revisión a diferentes casos de uso. Eso que comenta Guerrero se lo
pregunté personalmente, e hicimos una gran extensión del concepto junto
con su implementación en SQLServer (dónde él es un maestro).



>De la teoría debemos bajar a la práctica, o sea implementar. Si

implemento
Mostrar la cita

>en SQL Server , debo evitar NULLs, o complicarme en las consultas.
>Si implemento en Oracle, tendré otros problemas, y así sucesivamente. Si
>IGNORO los consejos bibliográficos, seguramentes las consultas me

devolveran
Mostrar la cita

>"chorizos" y chocaré como buen ignorante con los mismos errores que ya

otros
Mostrar la cita

>chocaron.
>Solo pretendía evitarle (transmitiendo consejos de gente que sabe mucho)

a
Mostrar la cita

>Alberto Muñoz dolores de cabeza.

>Salu2
>Nelson

"Esparta Palma" escribió en el
mensaje news:O3Slj$
> Ese libro lo tengo, y platiqué en persona con Guerrero sobre eso y otras
> cosas, y que sea un excelente no me quita la idea de que si no SQLServer
> no es el único servidor en el mundo, si se aumenta la complejidad, pues

es
Mostrar la cita

> problema de SQLServer. De lo que yo hablo y nunca mencioné proovedores

es
Mostrar la cita

> teoría pura de base de datos, la cual los fabricantes deberían

implementar
Mostrar la cita

> sin aumentar complejidad.
>
> >Otra bibliografía:
> >"Programación en Microsoft SQL Server 2000" Con ejemplos, de Guerrero

y
Mostrar la cita

> >Carlos Eduardo Rojas. Página 139 se puede apreciar lo que significa
> >complejidad en el otro libro citado, referido a la contemplación de los
> >valores NULL en los campos que participan en la cláusula WHERE.
> >Salu2
> >Nelson
>
> "Esparta Palma" escribió en el
> mensaje news:%23$
> > Desaconsejable?
> > Yo no diría eso, hay casos muy específicos en dónde es necesario, y
> > cualquier "consejo" lo tienes que tirar por la borda, por ejemplo, si
> > guardas la fecha en que das de baja un item de tu inventario, que

fecha
Mostrar la cita

le
> > pones si tu item sigue en uso??, la fecha de hoy?, la fecha de un
> > aproximado?, pues no, le pones NULL!!
> >
> > El concepto de NULL es algo muy interesante, ha formado una revolución
en
> > los conceptos de base de datos, ya que un valor NULL tiene la

capacidad
Mostrar la cita

de
> > ser nada y a la vez significar algo, algo muy parecido a lo ocurrido

con
Mostrar la cita

> > la invención del número cero (cortesía de los pueblos Mayas) .
> >
> > El concepto de NULL ayuda bastante a darse cuenta de lo que no se
conoce,
> > y generalmente responde a todas las preguntas con un "No lo sé":
> >
> > 1.- ¿En que fecha te moriste? --> NULL --> No lo sé, sigo vivo.
> > 2.- ¿Cuantos años tenias cuando te divorciaste? --> NULL -> No lo sé,
> > nisiquiera me he casado
> > 3.- ¿Cuanto dinero ganas con tu jubilación? --> NULL --> No lo sé, no

me
Mostrar la cita

> > he jubilado, sigo trabajando
> >
> > Así pues, considero que *no* es "desaconsejable" el uso de NULLs, en
otras
> > palabras, lo debe usar sólo en los casos en que no se sabe con certeza
las
> > cosas, que de casos hay muchos. Por otro lado, quizás sea incómodo su
uso
> > (para aquellos que inician en éstos conceptos), pero de que sea
> > desaconsejable, de ninguna manera, es más bien cuestión de
acostumbrarse,
> > como dirían otros:"Es como ir a un picnic y no encontrar hormigas"
> >
> > Claro está que en algunos casos le puedes poner algo que según TU modo
de
> > ver signifique "algo", por ejemplo, si la fecha de nacimiento y
defunción
> > es la misma y una banderita de finado *no* está puesta, entonces no
sabes;
> > o si le pones cero en los años de divorciado, entonces no se ha
> > divorciado; o si le pones $0 a la cantidad ganada en tu jubilación...
ahhh
> > entonces NO está jubilado. Si, es fácil, es sencillo, pero incurres en
> > graves problemas debido a que estás falseando una información y se cae
en
> > ambiguedades relativas a interpretaciones personales, ya que desde un
> > inicio, lo que quisiste decir fué "No lo sé", para qué complicarse la
vida
> > ?, si no lo sabes, dilo, pero no inventes. Las bases de datos deben

ser
Mostrar la cita

> > confiables y no presentar inconherencias nunca.
> >
> > Saludos!
> >
> >
> > >De todas maneras ten en cuenta que altamente desaconsejable dejar
campos
> > >con valor NULL dentro de las tablas SQL Server ya que si participan
> alguna
> > >vez en consultas SELECT los resultados son impredecibles, a no ser,
> claro,
> > >que los tengas en cuenta y escribas las SELECT para no considerar.
> > >Salu2
> >
> > >Nelson Rodriguez
> > >Salto - Uruguay
> > >
> >
> > "Alberto Muñoz" escribió en el mensaje
> > news:eX$
> > > Hola Grupo.
> > >
> > > Hay alguna forma de evitar que se grabe en la tabla la fecha
01/Ene/1900
> > > cuando el usuario deja vacio el campo de fecha y oprime el botón
grabar
> en
> > > la aplicación?
> > >
> > > Es posible dejar el campo fecha vacío sin que se grabe esta fecha?
> > >
> > > Gracias por cualquier ayuda.

¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway