Campos NULL

23/06/2008 - 17:45 por Penta | Informe spam
Estimados.
Al crear unas tablas nuevas, me envian campos que aceptan valores
null, se justifica ? y porque ??

Ejemplo:

CODIGO INT NOT NULL
DESCRIPCION VARCHAR(20) NULL ' Esta campo no se justifica que sea
null
ESTADO INT NULL ' Pero este campo perfectamente podria ser null no ??


Atte.
Penta.

Preguntas similare

Leer las respuestas

#6 Gux (MVP)
23/06/2008 - 19:58 | Informe spam
El problema es que aún los autores clásicos como Codd han mencionado "valores
nulos" en sus obras. Por ejemplo en el título de la Regla 3 (de sus reglas
para calificar a un sistema de base de datos como "relacional") dice "null
values".

Por supuesto que en la definición de la regla se aclara que "null" deberá
ser una representación diferente de los valores regulares usados por
cualquiera de los tipos de datos.

Rule 3: Systematic treatment of null values:
The DBMS must allow each field to remain null (or empty). Specifically, it
must support a representation of "missing information and inapplicable
information" that is systematic, distinct from all regular values (for
example, "distinct from zero or any other number," in the case of numeric
values), and independent of data type. It is also implied that such
representations must be manipulated by the DBMS in a systematic way.

Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Carlos M. Calvelo" wrote:

On 23 jun, 18:41, "Maxi" wrote:
> Queria decir valor :(
>
> A value of NULL indicates the value is unknown. A value of NULL is different
> from an empty or zero value
>

Un null no es un valor.
O si lo quieres en inglés:
Null is not a value. It's a mark indicating that there is no value.

Respuesta Responder a este mensaje
#7 Carlos M. Calvelo
23/06/2008 - 21:04 | Informe spam
Hola Gux,

On 23 jun, 19:58, Gux (MVP) wrote:
El problema es que aún los autores clásicos como Codd han mencionado "valores
nulos" en sus obras. Por ejemplo en el título de la Regla 3 (de sus reglas
para calificar a un sistema de base de datos como "relacional") dice "null
values".




Eso no es problema.
El trabajo de Codd en cuanto al problema del "missing information"
en el aspecto en como ha tratado los nulos está obsoleto.
El modelo relacional evoluciona y la investigación sigue.

(Lo mismo para lo que sigue aquí abajo)

Por supuesto que en la definición de la regla se aclara que "null" deberá
ser una representación diferente de los valores regulares usados por
cualquiera de los tipos de datos.

Rule 3: Systematic treatment of null values:
The DBMS must allow each field to remain null (or empty). Specifically, it
must support a representation of "missing information and inapplicable
information" that is systematic, distinct from all regular values (for
example, "distinct from zero or any other number," in the case of numeric
values), and independent of data type. It is also implied that such
representations must be manipulated by the DBMS in a systematic way.





Todo valor tiene que tener un tipo; o sea tiene que pertenecer
a un conjunto de valores que es parte esencial de la definición
de algún tipo. Otra propiedad fundamental de valores es ser iguales
a si mismos; o sea que diferentes apariciones del mismo valor
tienen la propiedad de ser iguales siempre (son el mismo valor.)

Dos propiedades básicas, fundamentales de lo que es
un valor. Null no posee ninguna de ellas. No es un valor.

Saludos,
Carlos
Respuesta Responder a este mensaje
#8 Penta
23/06/2008 - 21:55 | Informe spam
On 23 jun, 12:32, "Carlos M. Calvelo" wrote:
On Jun 23, 5:45 pm, Penta wrote:

> Estimados.
> Al crear unas tablas nuevas, me envian campos que aceptan valores
> null, se justifica ? y porque ??

> Ejemplo:

> CODIGO INT NOT NULL
> DESCRIPCION  VARCHAR(20) NULL  ' Esta campo no se justifica que sea
> null
> ESTADO INT NULL ' Pero este campo perfectamente podria ser null no ??

A INT NOT NULL
B VARCHAR(20) NULL
C INT NOT NULL

Puedes tu justificar por qué A y C no pueden ser null y B sí?
y por qué?



El campo A no es NULL ya qque es PK.
El campo B no deberia ser NULL porque es la descripcion del campo A
El campo C tengo la duda, ya que perfectamente podria ser NULL ya que
en primera instancia no tendria porque tener un valor.
Pero segun las bases de la 1FN

Primera Forma Normal (1FN) Una tabla está en Primera Forma Normal
sólo si
.
.
La tabla no contiene atributos nulos
etc.
Respuesta Responder a este mensaje
#9 Gux (MVP)
23/06/2008 - 22:22 | Informe spam
Hola Carlos M. Calvelo,

"Carlos M. Calvelo" wrote:

El trabajo de Codd en cuanto al problema del "missing information"
en el aspecto en como ha tratado los nulos está obsoleto.
El modelo relacional evoluciona y la investigación sigue.




Interesante. Personalmente hace unos diez años que no estoy cercano a temas
de investigación académica.

Si no es molestia, puede usted indicarme material actualizado acerca del
tema de los nulos y la obsolecencia de los conceptos tratados por Codd?

Saludos, gracias desde ya.

Gustavo Larriera, Microsoft MVP
http://www.linkedin.com/in/gustavolarriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Respuesta Responder a este mensaje
#10 Carlos M. Calvelo
23/06/2008 - 22:22 | Informe spam
On 23 jun, 21:55, Penta wrote:
On 23 jun, 12:32, "Carlos M. Calvelo" wrote:





> On Jun 23, 5:45 pm, Penta wrote:

> > Estimados.
> > Al crear unas tablas nuevas, me envian campos que aceptan valores
> > null, se justifica ? y porque ??

> > Ejemplo:

> > CODIGO INT NOT NULL
> > DESCRIPCION VARCHAR(20) NULL ' Esta campo no se justifica que sea
> > null
> > ESTADO INT NULL ' Pero este campo perfectamente podria ser null no ??

> A INT NOT NULL
> B VARCHAR(20) NULL
> C INT NOT NULL

> Puedes tu justificar por qué A y C no pueden ser null y B sí?
> y por qué?

El campo A no es NULL ya qque es PK.



Que CODIGO es la clave primaria es información nueva.

El campo B no deberia ser NULL porque es la descripcion del campo A



Que el código deba o no deba tener una descripción es algo que
depende de la situación que estés tratando de modelar.

El campo C tengo la duda, ya que perfectamente podria ser NULL ya que
en primera instancia no tendria porque tener un valor.



Si en la situación que tratas de modelar, ESTADO no tiene por
qué tener un valor, pues podría ser null, o podrías tener
otra tabla:

CODIGO INT NOT NULL PRIMARY KEY,
ESTADO INT NOT NULL

siendo Codigo también un FK a la tabla anterior.


Pero segun las bases de la 1FN

Primera Forma Normal (1FN) Una tabla está en Primera Forma Normal
sólo si
.
.
La tabla no contiene atributos nulos
etc.



Como lo estoy entendiendo yo esto no tieme nada que ver con 1NF.


No pareces haber entendido mi reacción. Qué columnas tienen
que permitir nulos o no solo depende de la situación que
estás tratando de modelar. De eso no has dicho nada.
Presentas algo, digamos.. como un modelo y preguntas si
está bien y por qué. Nadie puede responder esa pregunta.
Un modelo de qué? Que situación estás tratando de modelar?

Maxi te ha respondido bién:
"eso va a depender de lo que quieras hacer"

Pero no dices nada de lo que quieres hacer, solo dices lo que
estás haciendo.
Cualquiera que te diga que está bien o mal, o no sabe lo que
dice o te está mintiendo. Porque simplemente no puede saberlo.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida