Base de datos.

[jk16]

Hola chapuzillas....os cuento :

Tengo un pequeño lío con la creación de una base de datos de una floristería.

Alguno tiene algún ejemplo de alguna base de datos de una tienda online?

A la hora de crear las tablas y sus relaciones en la base de datos,no sé como interpretar que un un cliente puede realizar el pedido de dos maneras , registrándose o no ( simplemente introduciendo sus datos )

También me gustaría saber como reflejas en la base de datos , los descuentos..promociones..etc

Si alguno me puede echar un cable se lo agradecería.

Saludos

 

[Borja Rodríguez]

Ni fruta... te lo dubo. no sé si David Rey sabrá.

 

[David Rey]

Ni idea, yo de programación cero. Pero lo tengo claro si quiero hacer alguna cosa de esas, usaría un gestor CMS para ello.

 

[pabs11]

A ver, por partes.

El pedido lo hara igual, puedes asignar un ID de cliente registrado, y otro de no registrado, o simplemente, una columna REGISTRADO

Descuentos y promociones igual, una tabla con TODOS los tipos de descuentos, y en la de pedidos, pones una columna DESCUENTOS y le pones cada vez el id del descuento. Así sabes si es del 15%, o envio gratis, etc.

 

[jk16]

Gracias pabs11

Creo dos tablas de clientes ? uno para cada caso?? o una sola tabla de clientes donde tenga el id_cliente registrado , id_cliente no registrado??

A la hora de dar permisos ,un cliente registrado tendrá mas información y opciones que uno que no lo esté..eso supongo que lo tendré que hacer mediante PHP ..

Algún programador tiene algún modelo lógico parecido ???

graciasssss

 

[Drami24]

Otra opción es que hagas una superclase

De esta forma podrás poner los atributos comunes a la superclase llamada clientes y diferenciarlas en las subclases.

Otro ejemplo:

 

[pabs11]

Gracias pabs11

Creo dos tablas de clientes ? uno para cada caso?? o una sola tabla de clientes donde tenga el id_cliente registrado , id_cliente no registrado??

A la hora de dar permisos ,un cliente registrado tendrá mas información y opciones que uno que no lo esté..eso supongo que lo tendré que hacer mediante PHP ..

Algún programador tiene algún modelo lógico parecido ???

graciasssss

Sinceramente. ¿Qué nivel de PHP tienes?

Yo haria un if de tipo si el id ==0 usuario no registrado, por tanto, opciones de no registrado sino, opciones de registrado.

Más o menos, el 0 es un ejemplo, pero debería ser un id único, ningún cliente puede tener ese id

Enviado desde mi XT1021 mediante Tapatalk

 

[josejfernandez]

¿Tienes algún diagrama (E/R, UML) para poder compartir?

Los pedidos están relacionados con los clientes, que pueden o no estar registrados. Esto sería un atributo, que en la implementación podría tomar la forma de un campo tinyint o bit(1) llamado is_registered, por ejemplo. Luego la teoría relacional puede indicar que son dos subtipos pertenecientes a un supertipo y blahblahblah, lo cual implicaría a 2-4 tablas...

Por motivos de practicidad y rendimiento, puedes tener una tabla tal que esta:

Customer ([U]id[/U], name, email[VARCHAR NULL], password[CHAR NULL], secure_salt[CHAR NULL], [B]is_registered[/B][TINYINT|BIT(1)], ...)

De modo que cualquier pedido va relacionado con su cliente, esté o no registrado, y que como cliente puede tener direcciones de facturación y envío.

En cuanto a los descuentos, habría mil maneras. Tienes que plantear una que cumpla con los requisitos del negocio y que te simplifique las cosas. Puedes plantear que cada entrada de un pedido (aquí hay dos entidades no muy visibles: Pedido y LíneaPedido) vaya asociada con el pedido -evidentemente- y con los descuentos que se apliquen. O relacionar el pedido con los descuentos (N:M) y controlar desde la aplicación cómo afectan esos descuentos al pedido. Hay mil maneras. Debes plantear el resto del sistema y tener bien claros tus requisitos y diseñar una solución en base a eso.

Porque depende de muchísimas cosas: si sólo harás descuentos porcentuales sobre el precio total del pedido, si harás descuentos a unos productos concretos, si tendrán condiciones... Todo eso complica el diseño y la estructura. Si sólo vas a hacer descuentos porcentuales sobre el precio total de un pedido, es el caso más simple: atributo descuento, tipo de dato TINYINT UNSIGNED NOT NULL DEFAULT 0, y a la hora de calcular es sencillísimo.

Pero si vas a tener descuentos parametrizados, por segmentos... Pues no es lo mismo.

Depende de tus necesidades. No has facilitado casi nada.