¿Me echáis una mano con algo de teoría?

Bueno si de cuestiones de gustos se trata pues hay muchos tipos de
gustos es de ke introducir valores null es una solución chapucera me
suena a ke son gustos personales ahora si tienen algún link o libro ke
recomienden o lo ke sea ke se salga de los gustos personales y sea más
una cuestión de un estandar internacional o porke un renombrado autor
asi lo dice entonces aganmelo saber porke desde mi punto de vista los
valores null no tiene nada de chapuseros

Hola:

No creo que sea cuestión de gustos o no, a mi me enseñaron a la forma de
Víctor o Alfredo y en la vida se me ocurriría crear una foreign key que
pudiera contener nulos. Seguramente ellos te puedan documentar esto mejor
que yo. Pero sí se de gente que opina como tu, que se puede apuntar a un
null sin ningún problema... A mi eso me suena más a lenguajes de
programación tipo C, C++, etc... no a diseño de base de datos donde la
integridad referencial es básica.

Pero bueno, que hablen los expertos :)

Juan Diego Bueno www.moondance.tk

escribió en el mensaje
news:
Bueno si de cuestiones de gustos se trata pues hay muchos tipos de
gustos es de ke introducir valores null es una solución chapucera me
suena a ke son gustos personales ahora si tienen algún link o libro ke
recomienden o lo ke sea ke se salga de los gustos personales y sea más
una cuestión de un estandar internacional o porke un renombrado autor
asi lo dice entonces aganmelo saber porke desde mi punto de vista los
valores null no tiene nada de chapuseros

Talvez tengas razón yo no soy experto en base de datos yo me considero
más un desarrollador de software ke un diseñador de base de datos pero
como una consa lleva a la otra tengo ke saber base de datos pero la
llaves foraneas admiten valores null yo no le veo nada de malo porke
por lo general en mis aplicaciones pertenecen a las tablas ke hacen la
función de catálogos y cuando kiero ke el usuario pueda indicar o no
indicar una opción del catálogo le permito ke pueda indicar o no
indicar el campo
ahora me pregunto:

¿cómo le hacen cuando un campo es opcional? a caso utilizan un
registro comodín o ke?

porke lo ke yo hago ya lo explique lo utilizo en dos escenarios ke ya
he explicado

1. si la opción de indicar un cupon al pedido es arbitraria utilizar
el registro comodin es una buena solución porke no validaras ningun
tipo de información en la aplicación

2. si la opción de indicar un cupon al pedido no es arbitraria es
decir ke ciertos esenarios el usuario forzosamente debe de indicar un
cupon y en otros esenarios no entonces la opción del registro comodín
no es la recomendable porke es casi seguro ke desde tu aplicación
tendras ke hacer una validación con respecto a los datos de un
registro en la base de datos y así amarraras tu aplicación a un
registro de la base de datos y
eso no debe ocurrir

un ejemplo alguien estaria haciendo esto con el registro comodín desde
la aplicación diseñada en .net utilizando c#

if (mivariable.equals("NO ESPECIFICADO"))
{
//hacer algo
}

si se dan cuenta "NO ESPECIFICADO" es un dato en la base de datos
ahora imaginense si le cambian el nombre y en su aplicación
escribieron muchas lineas de código con este tipo de validación
obviamente su aplicación kedara inservible y modificarla será una
pesadilla si su aplicación tiene cientos de miles de lineas de código
es por eso a mi amigo le recomiendo ke estudie bien el escenario antes
de decidir

Hola jc:

Bueno, yo tampoco me considero ningún experto en base de datos, ni como
desarrollador, pero sí en contínuo aprendizaje. Pero te cuento como me
explicaron a mi para resolver las situaciones de opcionalidad:

- Si la relación es M:M se resuelve igual que siendo obligatoria, ya que hay
que recurrir a una tabla relación que contenga claves foráneas que hagan
referencia a las claves principales de las tablas relacionadas.
- Si la relación es 1:M Opcional-Opcional u Obligatoria-Opcional se resuelve
creando una tabla relación nueva cuya clave primaria es la que participa
como M
- Si la relación es 1:1 Obligatoria-Opcional a la que participa de forma
opcional se le añade la clave primaria de la obligatoria como clave foránea
y si es Opcional-Opcional hay que volver a recurrir a una tabla relación
cuya clave primaria será una cualquiera de las dos tablas a relacionar (y lo
suyo es que la otra clave foránea que contiene la tabla tenga una
restricción unique)

Como verás, en casi todas las opciones se crea una tabla nueva en la que se
crea un registro si hay relación con la otra tabla, y sino, simplemente, se
quedan las cosas como está.

Como se dijo al principio, luego se puede crear una vista con una outer join
en la que en el caso de que no hubiera registro relacionado aparecería null
o en su defecto, se usaría isnull(campo, valor) para mostrar un valor por
defecto.

Lo de usar el registro comodín es una opción que yo he usado alguna vez,
sobre todo para importar de forma fácil tablas creadas con otro diseño y
cumple con su función, pero es cierto que deja una especie de registro
'fantasma' y se debería tender a no usarlo.

Me llamó la atención tu respuesta porque hace no mucho un colega me planteó
algo similar y a mi nunca me gustó esa opción, pensé que apenas se usaba.

Lo que no tengo es ningún buen link que explique convincentemente el por qué
de hacerlo así (seguro que viene en el libro de Date, pero hay que
comprarlo, claro).

Supongo que queda abierto otro debate.

Saludos

Juan Diego Bueno www.moondance.tk

escribió en el mensaje
news:
Talvez tengas razón yo no soy experto en base de datos yo me considero
más un desarrollador de software ke un diseñador de base de datos pero
como una consa lleva a la otra tengo ke saber base de datos pero la
llaves foraneas admiten valores null yo no le veo nada de malo porke
por lo general en mis aplicaciones pertenecen a las tablas ke hacen la
función de catálogos y cuando kiero ke el usuario pueda indicar o no
indicar una opción del catálogo le permito ke pueda indicar o no
indicar el campo
ahora me pregunto:

¿cómo le hacen cuando un campo es opcional? a caso utilizan un
registro comodín o ke?

porke lo ke yo hago ya lo explique lo utilizo en dos escenarios ke ya
he explicado

1. si la opción de indicar un cupon al pedido es arbitraria utilizar
el registro comodin es una buena solución porke no validaras ningun
tipo de información en la aplicación

2. si la opción de indicar un cupon al pedido no es arbitraria es
decir ke ciertos esenarios el usuario forzosamente debe de indicar un
cupon y en otros esenarios no entonces la opción del registro comodín
no es la recomendable porke es casi seguro ke desde tu aplicación
tendras ke hacer una validación con respecto a los datos de un
registro en la base de datos y así amarraras tu aplicación a un
registro de la base de datos y
eso no debe ocurrir

un ejemplo alguien estaria haciendo esto con el registro comodín desde
la aplicación diseñada en .net utilizando c#

if (mivariable.equals("NO ESPECIFICADO"))
{
//hacer algo
}

si se dan cuenta "NO ESPECIFICADO" es un dato en la base de datos
ahora imaginense si le cambian el nombre y en su aplicación
escribieron muchas lineas de código con este tipo de validación
obviamente su aplicación kedara inservible y modificarla será una
pesadilla si su aplicación tiene cientos de miles de lineas de código
es por eso a mi amigo le recomiendo ke estudie bien el escenario antes
de decidir

Hola a todos de nuevo.

Vaya debate se ha montado :)

En el caso del proyecto que estoy realizando, entre las posibilidades
de utilización de cupones tendremos estas:

- Un pedido utiliza UN SOLO cupón, nunca más de uno.
- Varios pedidos pueden utilizar el mismo cupón.
- Habrán pedidos que no utilicen ningún cupón.

Dicho esto, leyéndoos he recapacitado y es cierto que no me parece la
manera más "limpia" lo de utilizar el registro-comodín. Quizá me
convenció en un principio porque yo también soy más desarrollador de
software que experto en bases de datos.

Viendo las cosas con algo más de perspectiva después de leeros, me
parece que la opción indicada sería, tal como dijo Alfredo Novoa, lo
de utilizar una tabla intermedia de esta forma:

PEDIDOS
IDPedido
Descontado (cantidad descontada después de aplicar el cupón)

CUPONES
=IDCupon
Nombre
Caducidad
Descuento

CUPON_PEDIDO
IDPedido
IDCupon


¿Os parece bien para esta casuística particular?

Muchas gracias a todos por vuestra ayuda.