SQL SERVER fecha 01/Ene/1900

En efecto, no pensamos igual, toda esta discusión (que son de las cosas
que me encanta de estos lugares) se comenzó por el cómo leí tu mensaje, a
mí me suena a: "Nunca, pero nunca de los nuncas uses valores NULL", el
porqué lo digo? bueno, resulta que altamente desaconsejable me parece que
una autoridad superior lo designa, pero afortunadamente en cosas de
sistemas no hay nadie que puede darse el lujo de decir algo así (bueno,
quizás LuisMa, ya vez que luego se le sube lo celeste a la cabeza y ni
quien lo aguante)

Así pues, creo deberíamos concluir con ver si estamos de acuerdo a que
siempre habrá casos especiales, incluso F. Guerrero (a quien citaste
inicialmente) lo comenta públicamente (y a nivel mundial) sin
contradecirse en lo que dice en su libro, ya que aunque fuere "altamente
desaconsejable", lo comenta con franca tranquilidad, siempre habrá un
momento en que uses valores NULL, pero tomandolo con precuación, incluso,
el uso de IS NULL lo recomienda. En otro post comenta otro caso, Todos los
empleados tienen licencia de manejar? Respuesta... NULL. (Ojo, aquí no
aplica el "Será inocente hasta que se compruebe lo contrario", por lo que
no puedes suponer si tienen o no tienen licencia)

Entonces, mi postura no es de poner NULL a todo, sino sólo en los casos en
que pudiere ser necesario, y si lo usaras, aguantarse y prevenirse los
casos.

Con respecto a respetar la bibliografía, pues si, tengo unos 10 libros
sobre el tema (Diseño e Implementación de Bases de Datos), unas centenas
de artículos electrónicos, y varios miles de mensajes en los newsgroups
que me han formado mi idea del mundo de base de datos, y en donde he
aprendido a que las recomendaciones absolutas no tienen ningún sentido.

Además, para cerrar la discusión, yo tengo el libro de F. Guerrero firmado
por el mísmo, por lo que me debe de dejar más autoridad al exponer lo que
él dice :-D !!! (Just Kidding)

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



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

Hola como estas, estoy en parte deacuerdo con tus comentarios, pero hay
campos que es mejor dejarlos null, para aquellos campos que serán usados
frecuentemente en los select como fecha de nacimiento, fecha de emisión,
Etc, es mas eficiente colocarles un valor por omisión, pero campos como
fecha de defunción, fecha de cierre, etc que son campos que son utilizados
solo cuando el evento ocurre es mejor dejarlos null, es un poco mas de
trabajo el hacer este tipo de analisis, pero a mi parecer es mas eficiente.

Saludos,



________________________
José G. Samper C.
MCAD/MCSD/MCDBA
http://www.FoxyNet.Net


"Nelson Rodriguez" escribió en el mensaje
news:%

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.