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

On 5 nov, 18:23, "" wrote:

Yo no estoy de acuerdo con la respuesta anterior desde mi punto de
vista lo ke tienes es una relación de uno a muchos

Es una relación de 1 a 0 o 1, y lo mejor en estos casos desde el punto
de vista de la teoría es crear otra tabla.

PEDIDOS
> IDPedido
IDCupon , null
Descontado

Esta solución es bastante chapucera por que usa nulos.

ahora bien otra forma ke yo utilizo es ke en tucaso en la tabla
CUPONES agregues un nuevo registro como por ejemplo (NO ESPECIFICADO)
o NO APLICA como tu le kiereas llamar para de esa forma los usuarios
desde la aplicación indiquen ke al pedido ke están generando no
aplica los cupones

Esto es mejor que lo del nulo, pero no es muy elegante por que estás
creando un cupón ficticio cuando es mucho más lógico que simplemente
no establezcas ninguna relación entre ese pedido y ese cupón no
introduciendo ningún registro en la tabla CUPON_PEDIDO.


Saludos

On 5 nov, 19:05, "Victor Koch" <v i c t o r
(arroba)correo(punto)waldbott(punto)com(punto)ar> wrote:

Hola Masta,

Otra solucion sin necesidad de hacer una tabla de muchos a muchos.

PEDIDOS
> IDPedido (PK)
Descontado

CUPONES
=> IDCupon (PK)
IDPedido (FK)
Nombre
Caducidad
Descuento

Esta solucion contempla:

1.Pedidos sin cupones.
2.Pedios con mas de un cupon.

Pero no contempla cupones sin pedidos ni varios pedidos con el mismo
cupón.


Saludos

Alfredo,

Tal vez el colega Masta debería aclarar los alcances y las condiciones, por
ejemplo:

Pueden existir cupones sin pedidos.
Pueden existir varios cupones para un solo pedido.
Pueden existir varios pedidos para un solo cupon.

Yo creo que tu solución, tener una tabla de relaciones, seria la solución
mas elegante ya que contempla todas las combinaciones incluso previendo
futuros requerimientos, no nos olvidemos que los clientes primero piden una
cosa y luego cambian las reglas.

También estoy deacuerdo que usar NULL es una chapuseada.

Un saludo, Víctor Koch.


"Alfredo Novoa" escribió en el mensaje
news:
On 5 nov, 19:05, "Victor Koch" <v i c t o r
(arroba)correo(punto)waldbott(punto)com(punto)ar> wrote:

Hola Masta,

Otra solucion sin necesidad de hacer una tabla de muchos a muchos.

PEDIDOS
> IDPedido (PK)
Descontado

CUPONES
=> IDCupon (PK)
IDPedido (FK)
Nombre
Caducidad
Descuento

Esta solucion contempla:

1.Pedidos sin cupones.
2.Pedios con mas de un cupon.

Pero no contempla cupones sin pedidos ni varios pedidos con el mismo
cupón.


Saludos

Yo no estoy de acuerdo con la respuesta anterior desde mi punto de
vista lo ke tienes es una relación de uno a muchos y si es así no
necesitas una tabla intermedia ya ke solo es cuando es de muchos a
muchoas
ahora lo ke debes ver es si kieres una relación de cero o uno a muchos
porke si es así
la tabla PEDIDOS en la llave foranea deberá estar marcada como null
en este caso idcupon, asi podran existir registros en la tabla PEDIDOS
si necesidad que existan registros en la tabla CUPONES, si de lo
contrario kieres ke sea una relación uno a muchos la llave foranea no
debe aceptar valores null entienes lo importante es el tipo de
relación
0 o 1 a muchos o del tipo uno a muchos
PEDIDOS
IDPedido
IDCupon , null
Descontado


ahora bien otra forma ke yo utilizo es ke en tucaso en la tabla
CUPONES agregues un nuevo registro como por ejemplo (NO ESPECIFICADO)
o NO APLICA como tu le kiereas llamar para de esa forma los usuarios
desde la aplicación indiquen ke al pedido ke están generando no
aplica los cupones

Ok esa es una solución la de registro comodin como le llamas pero
debes de tomar en cuenta siertos esenarios puede ser la solución fácil
pero en ciertos esenarios yo no lo recomendaría como por ejemplo si al
crear pedidos en ciertas condiciones el usuario del sistema debde
especificar un cupon para el pedido porke si es así tendras ke
introducir una validación a tu sistema que vallide la variable comodin
yasea por su nombre o por su clave pero debes de considerar el
escenario en el ke alguien sin avisar cambia el nombre del registro
comodin o la elimina o la clave o +indce de ese registro comodin
cambia ya que esos datos pueden ser volatiles osa cambiar sin aviso y
si cambias estras amarrando todo tu sistema a un registro y si cambia
ese registro tu sistema puede quedar inservible te recomiedno ke
analises los escenarios
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 amarraras tu aplicación a un registro y
eso no debe ocurrir