[DISC] problema raro al sumar

Carlos,

Por mi parte te dire que a pesar de que al permitir valores NULL en ciertas
columnas trae consigo y incremento en las lineas de codigo necesarias para
ciertas operaciones, prefiero usar NULL cuando en realidad el valor es
desconocido. Por ejemplo:

Que ponemos en la columna (ultima_vez_que_se_actualizo datetime) cuando
insertamos un registro por primera vez?

Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha estado en una
consulta anteriormente?

Hay casos en los que yo prefiero usar NULL, pero tambien trato de evitar que
columnas con dominio cerrado puedan contener este valor, por ejemplo:

- estado_civil
- sexo
- fecha_de_nacimiento
- etc.

y de vez en cuando (sobre todo en modelos dimensionales) tambien hago uso de
puntos de referencia como 'N/A' u otro valor por defecto.

La pregunta es buena, TO NULL OR NOT TO NUL?

Mi respuesta es "depende".

Saludos,


AMB


"Carlos Sacristán" wrote:

La respuesta a la pregunta de "Aprendiz de Informatico" ya la dieron
correctamente tanto Alejandro como Gustavo, lo que ocurre es que cuando
surgen temas de este tipo siempre me asalta la misma duda:

¿qué opináis sobre el uso de NULL? Gente como Joe Celko no está en
absoluto de acuerdo, pero me gustaría saber vuestras propias experiencias y
opiniones


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Aprendiz de Informatico"
escribió en el mensaje
news:
> hola, quiza es un poco tonto este problema pero bueno...
>
> la cuestion es que hago consultas y guardo ciertos valores en variables,
> dentro de un stored procedure. Luego tengo que sumar todas esas variables
> haciendo
>
> set @Total = @Suma1 + @Suma2 + @Suma3
>
> en el ejemplo este, la unica variable que tiene un valor es Suma3, las
otras
> 2 estan "vacias" porque no habia nada que sumar en esas consultas. El
> problema es que cuando hago esa suma para Total que puse mas arriba, me da
> NADA, ni siquiera cero, como si fuera null o algo por el estilo, pero
tendria
> que dar el valor de Suma3 que es la unica que tiene algo. Aclaro que el
tipo
> de datos que estoy usando es numeric(10,2)
>
> que hago para que me sume todo ?
>
> aparentemente el problema es solo cuando hay variables que no tienen
valor,
> porque cuando las 3 variables Suma tienen algo, no hay problema.
>
> :-)

Alejandro, yo estoy contigo, pero ciertamente un "gusanillo" me empieza
a remover el estómago. Y es que, efectivamente, si un valor lo desconoces,
lo suyo es no ponerlo, es decir, usar NULL. Los casos que pones son claros,
la lógica aquí es aplastante: si no lo conoces, no lo pongas

Sin embargo en la base de datos esta lógica que aceptamos implica
situaciones que pueden dar lugar a error. Por ejemplo:

- usar COUNT(nombre_campo) puede dar lugar a resultados diferentes
según sea el campo NULL o NOT NULL; con los operadores WITH ROLLUP y WITH
CUBE ocurre lo mismo
- las aplicaciones cliente se complican porque tienen que tener en
cuenta si un campo es nulo o no para tener los resultados correctos
- el motor de la base de datos va a ser más eficiente (aunque
estemos hablando de pequeñas diferencias, éstas existen) si un campo no es
nulo que si lo es
- también depende de cómo estén establecidas las propiedades ANSI
(ANSI_NULLS), y la consulta devolverá diferentes resultados

Todas estos inconvenientes parece que son más que la decisión lógica de
no querer poner un valor que se desconoce. Pero ciertamente NULL para
nosotros significa algo, no?. ¿Qué cuesta entonces cambiarlo por otro valor
que sí que tenga "valor" (valga el juego de palabras)?. Volviendo a tus
ejemplos:

- "Que ponemos en la columna (ultima_vez_que_se_actualizo datetime)
cuando insertamos un registro por primera vez?" -> podríamos poner la fecha
de creación del registro. Ciertamente fue la última vez que se modificó,
verdad? Pasó de no existir a existir, así que esa fecha nos da una
información valiosa si lo comparamos con la columna (cuando_se_creo
datetime)
- "Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha
estado en una consulta anteriormente?" -> éste es mejor ejemplo, pero
ciertamente tampoco cuesta nada decidir que una fecha en concreto nos
indique que esa persona nunca haya estado en la consulta: una fecha futura
('99991231')

En fin, que parece que mi respuesta va más encaminada a no aceptar NULL,
pero te aseguro que no es así. Lo que ocurre es que siento que la razón que
defendemos para usarlos no tiene la fuerza suficiente para aguantar los
inconvenientes que aparecen



Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Alejandro Mesa" escribió en el
mensaje news:

Carlos,

Por mi parte te dire que a pesar de que al permitir valores NULL en

ciertas

columnas trae consigo y incremento en las lineas de codigo necesarias para
ciertas operaciones, prefiero usar NULL cuando en realidad el valor es
desconocido. Por ejemplo:

Que ponemos en la columna (ultima_vez_que_se_actualizo datetime) cuando
insertamos un registro por primera vez?

Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha estado en

una

consulta anteriormente?

Hay casos en los que yo prefiero usar NULL, pero tambien trato de evitar

que

columnas con dominio cerrado puedan contener este valor, por ejemplo:

- estado_civil
- sexo
- fecha_de_nacimiento
- etc.

y de vez en cuando (sobre todo en modelos dimensionales) tambien hago uso

de

puntos de referencia como 'N/A' u otro valor por defecto.

La pregunta es buena, TO NULL OR NOT TO NUL?

Mi respuesta es "depende".

Saludos,


AMB


"Carlos Sacristán" wrote:

> La respuesta a la pregunta de "Aprendiz de Informatico" ya la dieron
> correctamente tanto Alejandro como Gustavo, lo que ocurre es que cuando
> surgen temas de este tipo siempre me asalta la misma duda:
>
> ¿qué opináis sobre el uso de NULL? Gente como Joe Celko no está en
> absoluto de acuerdo, pero me gustaría saber vuestras propias

experiencias y

> opiniones
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Aprendiz de Informatico"

> escribió en el mensaje
> news:
> > hola, quiza es un poco tonto este problema pero bueno...
> >
> > la cuestion es que hago consultas y guardo ciertos valores en

variables,

> > dentro de un stored procedure. Luego tengo que sumar todas esas

variables

> > haciendo
> >
> > set @Total = @Suma1 + @Suma2 + @Suma3
> >
> > en el ejemplo este, la unica variable que tiene un valor es Suma3, las
> otras
> > 2 estan "vacias" porque no habia nada que sumar en esas consultas. El
> > problema es que cuando hago esa suma para Total que puse mas arriba,

me da

> > NADA, ni siquiera cero, como si fuera null o algo por el estilo, pero
> tendria
> > que dar el valor de Suma3 que es la unica que tiene algo. Aclaro que

el

> tipo
> > de datos que estoy usando es numeric(10,2)
> >
> > que hago para que me sume todo ?
> >
> > aparentemente el problema es solo cuando hay variables que no tienen
> valor,
> > porque cuando las 3 variables Suma tienen algo, no hay problema.
> >
> > :-)
>
>
>

Hola Carlos y Alejandro,
Leí atentamente sus comentarios porque el tema NULL me da y seguirá dando
demasiados problemas.
Tenemos un sistema de Tasas tercerizado, que no fue diseñado originalmente
con tablas SQL, aunque ahora sí lo son. Pero herencia de esa mutación, es la
presencia de valores NULL en la mayoría de los datos sin contenido.
El problema es que la mayoría de los datos con los que yo trabajo son
importes y porcentajes. Cuando saco estadísticas, que generalmente son el
resultado de varios SP, me lleva mucho más tiempo verificar la consistencia
de los resultados que el tiempo de desarrollo, podrán imaginarse lo que
significa un resultado erróneo en un balance anual!
En los sistemas que hago desde cero, no acepto NULL, prefiero algo más de
trabajo a la hora del diseño con valores por defecto o en el código de
incorporación de información validando, que un dato malo entregado en un
balance al Intendente.
Es mi humilde experiencia.
Saludos,
Liliana.

"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%

Alejandro, yo estoy contigo, pero ciertamente un "gusanillo" me

empieza

a remover el estómago. Y es que, efectivamente, si un valor lo desconoces,
lo suyo es no ponerlo, es decir, usar NULL. Los casos que pones son

claros,

la lógica aquí es aplastante: si no lo conoces, no lo pongas

Sin embargo en la base de datos esta lógica que aceptamos implica
situaciones que pueden dar lugar a error. Por ejemplo:

- usar COUNT(nombre_campo) puede dar lugar a resultados diferentes
según sea el campo NULL o NOT NULL; con los operadores WITH ROLLUP y WITH
CUBE ocurre lo mismo
- las aplicaciones cliente se complican porque tienen que tener en
cuenta si un campo es nulo o no para tener los resultados correctos
- el motor de la base de datos va a ser más eficiente (aunque
estemos hablando de pequeñas diferencias, éstas existen) si un campo no es
nulo que si lo es
- también depende de cómo estén establecidas las propiedades ANSI
(ANSI_NULLS), y la consulta devolverá diferentes resultados

Todas estos inconvenientes parece que son más que la decisión lógica

de

no querer poner un valor que se desconoce. Pero ciertamente NULL para
nosotros significa algo, no?. ¿Qué cuesta entonces cambiarlo por otro

valor

que sí que tenga "valor" (valga el juego de palabras)?. Volviendo a tus
ejemplos:

- "Que ponemos en la columna (ultima_vez_que_se_actualizo

datetime)

cuando insertamos un registro por primera vez?" -> podríamos poner la

fecha

de creación del registro. Ciertamente fue la última vez que se modificó,
verdad? Pasó de no existir a existir, así que esa fecha nos da una
información valiosa si lo comparamos con la columna (cuando_se_creo
datetime)
- "Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha
estado en una consulta anteriormente?" -> éste es mejor ejemplo, pero
ciertamente tampoco cuesta nada decidir que una fecha en concreto nos
indique que esa persona nunca haya estado en la consulta: una fecha futura
('99991231')

En fin, que parece que mi respuesta va más encaminada a no aceptar

NULL,

pero te aseguro que no es así. Lo que ocurre es que siento que la razón

que

defendemos para usarlos no tiene la fuerza suficiente para aguantar los
inconvenientes que aparecen



Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Alejandro Mesa" escribió en el
mensaje news:
> Carlos,
>
> Por mi parte te dire que a pesar de que al permitir valores NULL en
ciertas
> columnas trae consigo y incremento en las lineas de codigo necesarias

para

> ciertas operaciones, prefiero usar NULL cuando en realidad el valor es
> desconocido. Por ejemplo:
>
> Que ponemos en la columna (ultima_vez_que_se_actualizo datetime) cuando
> insertamos un registro por primera vez?
>
> Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha estado en
una
> consulta anteriormente?
>
> Hay casos en los que yo prefiero usar NULL, pero tambien trato de evitar
que
> columnas con dominio cerrado puedan contener este valor, por ejemplo:
>
> - estado_civil
> - sexo
> - fecha_de_nacimiento
> - etc.
>
> y de vez en cuando (sobre todo en modelos dimensionales) tambien hago

uso

de
> puntos de referencia como 'N/A' u otro valor por defecto.
>
> La pregunta es buena, TO NULL OR NOT TO NUL?
>
> Mi respuesta es "depende".
>
> Saludos,
>
>
> AMB
>
>
> "Carlos Sacristán" wrote:
>
> > La respuesta a la pregunta de "Aprendiz de Informatico" ya la

dieron

> > correctamente tanto Alejandro como Gustavo, lo que ocurre es que

cuando

> > surgen temas de este tipo siempre me asalta la misma duda:
> >
> > ¿qué opináis sobre el uso de NULL? Gente como Joe Celko no está en
> > absoluto de acuerdo, pero me gustaría saber vuestras propias
experiencias y
> > opiniones
> >
> >
> > Un saludo
> >
> > -
> > "Sólo sé que no sé nada. " (Sócrates)
> >
> > "Aprendiz de Informatico"

> > escribió en el mensaje
> > news:
> > > hola, quiza es un poco tonto este problema pero bueno...
> > >
> > > la cuestion es que hago consultas y guardo ciertos valores en
variables,
> > > dentro de un stored procedure. Luego tengo que sumar todas esas
variables
> > > haciendo
> > >
> > > set @Total = @Suma1 + @Suma2 + @Suma3
> > >
> > > en el ejemplo este, la unica variable que tiene un valor es Suma3,

las

> > otras
> > > 2 estan "vacias" porque no habia nada que sumar en esas consultas.

El

> > > problema es que cuando hago esa suma para Total que puse mas arriba,
me da
> > > NADA, ni siquiera cero, como si fuera null o algo por el estilo,

pero

> > tendria
> > > que dar el valor de Suma3 que es la unica que tiene algo. Aclaro que
el
> > tipo
> > > de datos que estoy usando es numeric(10,2)
> > >
> > > que hago para que me sume todo ?
> > >
> > > aparentemente el problema es solo cuando hay variables que no tienen
> > valor,
> > > porque cuando las 3 variables Suma tienen algo, no hay problema.
> > >
> > > :-)
> >
> >
> >

Liliana, yo creo que en el tema de estadísticas el uso de NULL es
todavía menos indicado por los problemas que comentas. Ahí pienso que
existen menos dudas en utilizarlos o no, verdad?

No sé, el caso es que yo antes estaba más de acuerdo por usarlos, pero
ciertamente o no veo o no existen las ventajas de aceptar NULL en la base de
datos...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Liliana Sorrentino" escribió en el mensaje
news:#SK#

Hola Carlos y Alejandro,
Leí atentamente sus comentarios porque el tema NULL me da y seguirá dando
demasiados problemas.
Tenemos un sistema de Tasas tercerizado, que no fue diseñado originalmente
con tablas SQL, aunque ahora sí lo son. Pero herencia de esa mutación, es

la

presencia de valores NULL en la mayoría de los datos sin contenido.
El problema es que la mayoría de los datos con los que yo trabajo son
importes y porcentajes. Cuando saco estadísticas, que generalmente son el
resultado de varios SP, me lleva mucho más tiempo verificar la

consistencia

de los resultados que el tiempo de desarrollo, podrán imaginarse lo que
significa un resultado erróneo en un balance anual!
En los sistemas que hago desde cero, no acepto NULL, prefiero algo más de
trabajo a la hora del diseño con valores por defecto o en el código de
incorporación de información validando, que un dato malo entregado en un
balance al Intendente.
Es mi humilde experiencia.
Saludos,
Liliana.

"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:%
> Alejandro, yo estoy contigo, pero ciertamente un "gusanillo" me
empieza
> a remover el estómago. Y es que, efectivamente, si un valor lo

desconoces,

> lo suyo es no ponerlo, es decir, usar NULL. Los casos que pones son
claros,
> la lógica aquí es aplastante: si no lo conoces, no lo pongas
>
> Sin embargo en la base de datos esta lógica que aceptamos implica
> situaciones que pueden dar lugar a error. Por ejemplo:
>
> - usar COUNT(nombre_campo) puede dar lugar a resultados

diferentes

> según sea el campo NULL o NOT NULL; con los operadores WITH ROLLUP y

WITH

> CUBE ocurre lo mismo
> - las aplicaciones cliente se complican porque tienen que tener

en

> cuenta si un campo es nulo o no para tener los resultados correctos
> - el motor de la base de datos va a ser más eficiente (aunque
> estemos hablando de pequeñas diferencias, éstas existen) si un campo no

es

> nulo que si lo es
> - también depende de cómo estén establecidas las propiedades

ANSI

> (ANSI_NULLS), y la consulta devolverá diferentes resultados
>
> Todas estos inconvenientes parece que son más que la decisión lógica
de
> no querer poner un valor que se desconoce. Pero ciertamente NULL para
> nosotros significa algo, no?. ¿Qué cuesta entonces cambiarlo por otro
valor
> que sí que tenga "valor" (valga el juego de palabras)?. Volviendo a tus
> ejemplos:
>
> - "Que ponemos en la columna (ultima_vez_que_se_actualizo
datetime)
> cuando insertamos un registro por primera vez?" -> podríamos poner la
fecha
> de creación del registro. Ciertamente fue la última vez que se modificó,
> verdad? Pasó de no existir a existir, así que esa fecha nos da una
> información valiosa si lo comparamos con la columna (cuando_se_creo
> datetime)
> - "Fecha_ultima_visita_al_doctor datetime, si la persona nunca

ha

> estado en una consulta anteriormente?" -> éste es mejor ejemplo, pero
> ciertamente tampoco cuesta nada decidir que una fecha en concreto nos
> indique que esa persona nunca haya estado en la consulta: una fecha

futura

> ('99991231')
>
> En fin, que parece que mi respuesta va más encaminada a no aceptar
NULL,
> pero te aseguro que no es así. Lo que ocurre es que siento que la razón
que
> defendemos para usarlos no tiene la fuerza suficiente para aguantar los
> inconvenientes que aparecen
>
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Alejandro Mesa" escribió en

el

> mensaje news:
> > Carlos,
> >
> > Por mi parte te dire que a pesar de que al permitir valores NULL en
> ciertas
> > columnas trae consigo y incremento en las lineas de codigo necesarias
para
> > ciertas operaciones, prefiero usar NULL cuando en realidad el valor es
> > desconocido. Por ejemplo:
> >
> > Que ponemos en la columna (ultima_vez_que_se_actualizo datetime)

cuando

> > insertamos un registro por primera vez?
> >
> > Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha estado

en

> una
> > consulta anteriormente?
> >
> > Hay casos en los que yo prefiero usar NULL, pero tambien trato de

evitar

> que
> > columnas con dominio cerrado puedan contener este valor, por ejemplo:
> >
> > - estado_civil
> > - sexo
> > - fecha_de_nacimiento
> > - etc.
> >
> > y de vez en cuando (sobre todo en modelos dimensionales) tambien hago
uso
> de
> > puntos de referencia como 'N/A' u otro valor por defecto.
> >
> > La pregunta es buena, TO NULL OR NOT TO NUL?
> >
> > Mi respuesta es "depende".
> >
> > Saludos,
> >
> >
> > AMB
> >
> >
> > "Carlos Sacristán" wrote:
> >
> > > La respuesta a la pregunta de "Aprendiz de Informatico" ya la
dieron
> > > correctamente tanto Alejandro como Gustavo, lo que ocurre es que
cuando
> > > surgen temas de este tipo siempre me asalta la misma duda:
> > >
> > > ¿qué opináis sobre el uso de NULL? Gente como Joe Celko no está

en

> > > absoluto de acuerdo, pero me gustaría saber vuestras propias
> experiencias y
> > > opiniones
> > >
> > >
> > > Un saludo
> > >
> > > -
> > > "Sólo sé que no sé nada. " (Sócrates)
> > >
> > > "Aprendiz de Informatico"
>
> > > escribió en el mensaje
> > > news:
> > > > hola, quiza es un poco tonto este problema pero bueno...
> > > >
> > > > la cuestion es que hago consultas y guardo ciertos valores en
> variables,
> > > > dentro de un stored procedure. Luego tengo que sumar todas esas
> variables
> > > > haciendo
> > > >
> > > > set @Total = @Suma1 + @Suma2 + @Suma3
> > > >
> > > > en el ejemplo este, la unica variable que tiene un valor es Suma3,
las
> > > otras
> > > > 2 estan "vacias" porque no habia nada que sumar en esas consultas.
El
> > > > problema es que cuando hago esa suma para Total que puse mas

arriba,

> me da
> > > > NADA, ni siquiera cero, como si fuera null o algo por el estilo,
pero
> > > tendria
> > > > que dar el valor de Suma3 que es la unica que tiene algo. Aclaro

que

> el
> > > tipo
> > > > de datos que estoy usando es numeric(10,2)
> > > >
> > > > que hago para que me sume todo ?
> > > >
> > > > aparentemente el problema es solo cuando hay variables que no

tienen

> > > valor,
> > > > porque cuando las 3 variables Suma tienen algo, no hay problema.
> > > >
> > > > :-)
> > >
> > >
> > >
>
>

Carlos,

El tema es interesante y voy a adjuntar un par de links que espero no haga
este tema mas dudoso.

> > - también depende de cómo estén establecidas las propiedades
ANSI
> > (ANSI_NULLS), y la consulta devolverá diferentes resultados

No se porque Microsoft incorporo este setting en SQL Server. ANSI_NULLS debe
estar siempre en ON, pues de lo contrario los resultados pueden ser
impredecibles y para probarlo voy a adjuntar un link a un test que quiciera
que ustedes lo tomaran juiciosamente para que vean a lo que me refiero.

A NULL Puzzle
http://groups.google.com/group/micr...2MSFTNGP12

Aca paso otro link de una prueba de rendimiento entre columnas con valores
NULL y sin ellos, esta interesante el resultado.

Performance Implications of Nullable Columns
http://sqljunkies.com/Article/96DC9...7B1FA.scuk

> > - "Fecha_ultima_visita_al_doctor datetime, si la persona nunca
ha
> > estado en una consulta anteriormente?" -> éste es mejor ejemplo, pero
> > ciertamente tampoco cuesta nada decidir que una fecha en concreto nos
> > indique que esa persona nunca haya estado en la consulta: una fecha
futura
> > ('99991231')

Con estos valores de referencia se debe tener mucho cuidado, documentarlos
muy bien y esperar a que todos los que programamos contra la db estemos al
tanto de las consecuencias de no tomar en cuenta estos valores. Si no los
tomamos en cuenta, los resultados pudieran estar mas disparados que si usamos
NULL (por ejemplo, calcular la media (en meses) de la
Fecha_ultima_visita_al_doctor respecto a la fecha actual). Otro ejemplo seria
usar un valor por defecto para el segundo nombre (millones no tenemos segundo
nombre y tampoco creo que mi segundo nombre es 'N/A', '', etc.).

En la vida real las cosas se comportan diferente a los modelos, y las
empresas no dejan de dar atencion a un cliente solo porque no recuerda el
"codigo postal" de su dirección. No creo que sea prudente usar un "codigo
postal" por default. Como este hay muchos casos mas. Ahora, lo mejor seria
que cuando ingresamos o recopilamos data sobre algo, que se tenga lo mas que
se pueda. En el caso de Liliana, pues existen reglas de negocio y / o
dominios definidos para los atributos de las entidades con las que ella
trabaja. Hablemos de un entidad financiera, por ejemplo, el saldo de una
cuenta siempre es conocido, una transaccion de credito o debito tiene un
valor asociado aunque este sea cero, etc. Cuando estas reglas de negocio no
son bien aplicadas o modeladas en nuestra db, entonces aparecen los problemas
como los que ella comenta.

Mi recomendacion es, si tienes regla de negocio entonces aplicala y te
evitaras muchos dolores de cabeza y tambien codigo.


AMB

"Carlos Sacristán" wrote:

Liliana, yo creo que en el tema de estadísticas el uso de NULL es
todavía menos indicado por los problemas que comentas. Ahí pienso que
existen menos dudas en utilizarlos o no, verdad?

No sé, el caso es que yo antes estaba más de acuerdo por usarlos, pero
ciertamente o no veo o no existen las ventajas de aceptar NULL en la base de
datos...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Liliana Sorrentino" escribió en el mensaje
news:#SK#
> Hola Carlos y Alejandro,
> Leí atentamente sus comentarios porque el tema NULL me da y seguirá dando
> demasiados problemas.
> Tenemos un sistema de Tasas tercerizado, que no fue diseñado originalmente
> con tablas SQL, aunque ahora sí lo son. Pero herencia de esa mutación, es
la
> presencia de valores NULL en la mayoría de los datos sin contenido.
> El problema es que la mayoría de los datos con los que yo trabajo son
> importes y porcentajes. Cuando saco estadísticas, que generalmente son el
> resultado de varios SP, me lleva mucho más tiempo verificar la
consistencia
> de los resultados que el tiempo de desarrollo, podrán imaginarse lo que
> significa un resultado erróneo en un balance anual!
> En los sistemas que hago desde cero, no acepto NULL, prefiero algo más de
> trabajo a la hora del diseño con valores por defecto o en el código de
> incorporación de información validando, que un dato malo entregado en un
> balance al Intendente.
> Es mi humilde experiencia.
> Saludos,
> Liliana.
>
> "Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
> news:%
> > Alejandro, yo estoy contigo, pero ciertamente un "gusanillo" me
> empieza
> > a remover el estómago. Y es que, efectivamente, si un valor lo
desconoces,
> > lo suyo es no ponerlo, es decir, usar NULL. Los casos que pones son
> claros,
> > la lógica aquí es aplastante: si no lo conoces, no lo pongas
> >
> > Sin embargo en la base de datos esta lógica que aceptamos implica
> > situaciones que pueden dar lugar a error. Por ejemplo:
> >
> > - usar COUNT(nombre_campo) puede dar lugar a resultados
diferentes
> > según sea el campo NULL o NOT NULL; con los operadores WITH ROLLUP y
WITH
> > CUBE ocurre lo mismo
> > - las aplicaciones cliente se complican porque tienen que tener
en
> > cuenta si un campo es nulo o no para tener los resultados correctos
> > - el motor de la base de datos va a ser más eficiente (aunque
> > estemos hablando de pequeñas diferencias, éstas existen) si un campo no
es
> > nulo que si lo es
> > - también depende de cómo estén establecidas las propiedades
ANSI
> > (ANSI_NULLS), y la consulta devolverá diferentes resultados
> >
> > Todas estos inconvenientes parece que son más que la decisión lógica
> de
> > no querer poner un valor que se desconoce. Pero ciertamente NULL para
> > nosotros significa algo, no?. ¿Qué cuesta entonces cambiarlo por otro
> valor
> > que sí que tenga "valor" (valga el juego de palabras)?. Volviendo a tus
> > ejemplos:
> >
> > - "Que ponemos en la columna (ultima_vez_que_se_actualizo
> datetime)
> > cuando insertamos un registro por primera vez?" -> podríamos poner la
> fecha
> > de creación del registro. Ciertamente fue la última vez que se modificó,
> > verdad? Pasó de no existir a existir, así que esa fecha nos da una
> > información valiosa si lo comparamos con la columna (cuando_se_creo
> > datetime)
> > - "Fecha_ultima_visita_al_doctor datetime, si la persona nunca
ha
> > estado en una consulta anteriormente?" -> éste es mejor ejemplo, pero
> > ciertamente tampoco cuesta nada decidir que una fecha en concreto nos
> > indique que esa persona nunca haya estado en la consulta: una fecha
futura
> > ('99991231')
> >
> > En fin, que parece que mi respuesta va más encaminada a no aceptar
> NULL,
> > pero te aseguro que no es así. Lo que ocurre es que siento que la razón
> que
> > defendemos para usarlos no tiene la fuerza suficiente para aguantar los
> > inconvenientes que aparecen
> >
> >
> >
> > Un saludo
> >
> > -
> > "Sólo sé que no sé nada. " (Sócrates)
> >
> > "Alejandro Mesa" escribió en
el
> > mensaje news:
> > > Carlos,
> > >
> > > Por mi parte te dire que a pesar de que al permitir valores NULL en
> > ciertas
> > > columnas trae consigo y incremento en las lineas de codigo necesarias
> para
> > > ciertas operaciones, prefiero usar NULL cuando en realidad el valor es
> > > desconocido. Por ejemplo:
> > >
> > > Que ponemos en la columna (ultima_vez_que_se_actualizo datetime)
cuando
> > > insertamos un registro por primera vez?
> > >
> > > Fecha_ultima_visita_al_doctor datetime, si la persona nunca ha estado
en
> > una
> > > consulta anteriormente?
> > >
> > > Hay casos en los que yo prefiero usar NULL, pero tambien trato de
evitar
> > que
> > > columnas con dominio cerrado puedan contener este valor, por ejemplo:
> > >
> > > - estado_civil
> > > - sexo
> > > - fecha_de_nacimiento
> > > - etc.
> > >
> > > y de vez en cuando (sobre todo en modelos dimensionales) tambien hago
> uso
> > de
> > > puntos de referencia como 'N/A' u otro valor por defecto.
> > >
> > > La pregunta es buena, TO NULL OR NOT TO NUL?
> > >
> > > Mi respuesta es "depende".
> > >
> > > Saludos,
> > >
> > >
> > > AMB
> > >
> > >
> > > "Carlos Sacristán" wrote:
> > >
> > > > La respuesta a la pregunta de "Aprendiz de Informatico" ya la
> dieron
> > > > correctamente tanto Alejandro como Gustavo, lo que ocurre es que
> cuando
> > > > surgen temas de este tipo siempre me asalta la misma duda:
> > > >
> > > > ¿qué opináis sobre el uso de NULL? Gente como Joe Celko no está
en
> > > > absoluto de acuerdo, pero me gustaría saber vuestras propias
> > experiencias y
> > > > opiniones
> > > >
> > > >
> > > > Un saludo
> > > >
> > > > -
> > > > "Sólo sé que no sé nada. " (Sócrates)
> > > >
> > > > "Aprendiz de Informatico"
> >
> > > > escribió en el mensaje
> > > > news:
> > > > > hola, quiza es un poco tonto este problema pero bueno...
> > > > >
> > > > > la cuestion es que hago consultas y guardo ciertos valores en
> > variables,
> > > > > dentro de un stored procedure. Luego tengo que sumar todas esas
> > variables
> > > > > haciendo
> > > > >
> > > > > set @Total = @Suma1 + @Suma2 + @Suma3
> > > > >
> > > > > en el ejemplo este, la unica variable que tiene un valor es Suma3,
> las
> > > > otras
> > > > > 2 estan "vacias" porque no habia nada que sumar en esas consultas.
> El
> > > > > problema es que cuando hago esa suma para Total que puse mas
arriba,
> > me da
> > > > > NADA, ni siquiera cero, como si fuera null o algo por el estilo,
> pero
> > > > tendria
> > > > > que dar el valor de Suma3 que es la unica que tiene algo. Aclaro
que
> > el
> > > > tipo
> > > > > de datos que estoy usando es numeric(10,2)
> > > > >
> > > > > que hago para que me sume todo ?
> > > > >
> > > > > aparentemente el problema es solo cuando hay variables que no
tienen
> > > > valor,
> > > > > porque cuando las 3 variables Suma tienen algo, no hay problema.
> > > > >
> > > > > :-)
> > > >
> > > >
> > > >
> >
> >
>
>