SQL SERVER fecha 01/Ene/1900

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

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

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

Definitivamente desaconsejable , por agregar complejidad y por motivos
propios de su manejo en SQL Server 2000, está en los libros de Microsoft y
otros.
Y cito:
Inside Microsoft SQL Server 2000. Kalen Delaney.
Página 235 y se extiende hasta 239.

Sin ánimo de polemizar.
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

Se puede definir un valor por default en un campo cuando el registro entra
sin valor en ese campo.
Si no sabe el valor en ese momento:
Numero --> guarde 0
String - > guarde ''
Fecha-> guarde '01/01/1900' , y se adopta esa fecha como NO
FECHA.

Salu2
Nelson

"Alberto Muñoz" escribió en el mensaje
news:%

Gracias Esparta !!
Definitivamente le tuve que poner el NULL precisamente porque el usuario
deja el campo vacío al llenar el formulario porque "No sabe" en el momento
su valor.
Saludos.


"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

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