Duda con relación en base de datos

smarquezp

Buenas noches señores! Acudo a vosotros porque tengo una duda con respecto a mi proyecto final de DAW y no se exactamente como hacerlo o si debería volver a formar la base de datos.

El caso es que estoy haciendo un proyecto de una página web simulando una bocatería, con PHP principalmente de backend. Estoy creando la base de datos y me ha surgido la duda de como realizarla realmente.

Partiendo de que tengo:
Tabla PRODUCTOS (contiene los bocadillos, pizzas, etc)
Tabla USUARIOS (con usuario, contraseña y tipo de usuario (admin o usuario normal))
Tabla CLIENTES (contiene los datos de los clientes con un campo llamado clienteUsuario, FK al usuario de USUARIOS)

Y aquí viene el problema, quería crear una tabla CARRITO, para hacer el carrito y una vez finalizase el pedido, se metiene en otra tabla llamada PEDIDOS, en los que irían los productos del propio carrito. Pero el problema es que no se como hacerlo realmente.

Quería hacer los datos de la tabla CARRITO temporales, es decir, cuando el usuario se saliese y terminase sesión o bien los datos llevasen x tiempo, se eliminasen. Entonces, ¿tendría que crear otra tabla con los datos de CARRITO, por ejemplo, CARRITO_FINAL, para relacionarlos con PEDIDOS?

O tal vez, la mejor opción sería hacer el carrito con una sesion de PHP y en el caso de que se finalizase el pedido, hubiese una tabla de PEDIDOS y otra con los datos del pedido?

La verdad es que es un poco lío y por mucho que busco por internet, los ejemplos son muy diferentes a lo que busco.

A ver si alguien pudiese echarme una mano, porque en el tema de crear las bases de datos estoy muy muy perdido.

Muchas gracias y un saludo!

AddeL1749

Yo te recomiendo que hagas un master-detail de la tabla pedidos.

Cabecera de pedidos - Identificador único del pedido, que usuario lo ha hecho, campos de control y precio total del pedido (que se calcula a partir de las líneas)
Líneas del pedido - Una línea del pedido por cada producto comprado, que indica el numero del pedido ( relacionándolo con la cabecera ), el identificador del producto, la cantidad del producto añadida y el precio unitario del pedido ( luego haces el calculo de cantidad*precio por cada línea y sumas todas las líneas para indicarselo a la cabecera mediante un update por ejemplo, si quieres tenerlo automatizado)

El como hacer el paso del front end al back end en php no te puedo ayudar mucho, solo curro con oracle y no web xD Pero dependiendo de los datos que saques en la pantalla de la base de datos puedes tirar de eso para después calcular todo.

1 respuesta
cabron

Una base de datos es para persistencia, si el carrito no persiste entre sesiones no tiene ningún sentido que tengas una tabla y lo guardes en base de datos, puedes usar redis, y si no quieres complicarte mucho y lo quieres hacer todo en php puedes usar apcu que es algo así como un redis dentro del propio interprete de php

1 respuesta
smarquezp

#2 Buenas!! Gracias por contestar.

Esa idea me parece bastante acertada, una vez realizado el pedido, se crea en la tabla PEDIDOS una línea con los datos en general como tal, y en otra, los detalles del pedido referenciándose al identificador único del pedido.

El caso que por ejemplo, cuando tu estás en la web y estás haciendo el carrito (elegir un producto de allí, otro de aquí, otros dos de otro lado), sería lo más acertado hacerlo todo en el cliente, no?
Es que yo en el ciclo lo había visto creando otra tabla llamada CARRITO, que sería parecida a la de los detalles del pedido, pero claro, serían dos tablas prácticamente iguales y no se hasta que punto es eficaz esto.

#3 Claro a algo así me refería, como los datos no van a ser para siempre, creo que guardarlos ahí no sería lo más ideal.
Voy a echar un vistazo a esto que me dices, gracias!

1 respuesta
Runig006

#4 Una chorrada que a la gente se le olvida.

Recurda que si guardos los pedidos, y se editan los precios, tienes que o cancelar el pedido o rescribirlo, o no guardar el precio. Lo digo porque no serias ni al primero ni al ultimo que cambia una promoción y/o precio, y se encuentra con 5-10 pedidos con la tarifa vieja.

Que son de esas chorradas que se piensan a posteriori y duelen que te cagas

1 2 respuestas
AddeL1749

#5 totalmente cierto, de ahí mi idea de que añadas el precio unitario del producto y sea un cálculo siempre.

Es decir yo haría en la tabla productos un campo que sea descuentos y el campo de precio unitario del detalle de pedidos sea en cálculo del precio base aplicándole los descuentos ( valores todos de la tabla producto )

1 respuesta
smarquezp

#5 #6 Esos detallitos no los tendré muy en cuenta. Si fuese una web real sí que lo vería más detenidamente, pero al querer "salir del paso" con la base de datos, querría ahorrármelo y no tocar mucho.
Cierto es que quedaría mucho mejor y más profesional, si veo que tengo tiempo de sobra lo miraré.

Muchas gracias por todo!!

eXtreM3
#1smarquezp:

O tal vez, la mejor opción sería hacer el carrito con una sesion de PHP y en el caso de que se finalizase el pedido, hubiese una tabla de PEDIDOS y otra con los datos del pedido?

Así es. Mantienes los productos del carrito en la sesión de Php y cuando se finaliza el pedido insertas en dos tablas:

  • PEDIDOS: una tupla con datos generales como id de usuario, precio total, fecha, método de pago...
  • PEDIDOS_INFO: aquí insertas una tupla por cada producto con datos como id de producto, precio unitario en el momento de la venta, unidades...

Así en el futuro siempre sabrás por qué un pedido costó X euros.


Y ya como extra, para rizar el rizo. Lo suyo sería que hicieses una tabla de histórico de precios donde guardes id de usuario, id de producto, precio anterior, precio nuevo, fecha.

Así sabes quién y cuándo ha hecho una modificación en los precios de un producto.

1 1 respuesta
smarquezp

#8 Buenas noches!! Perdona que te leí el mensaje y no te contesté ni siquiera, no me acordé.

Finalmente he decidido hacer eso mismo que dices, haré el carrito con arrays en una sesión de PHP y cuando se finalice, los introduciré en las tablas de PEDIDO y DETALLES_PEDIDO, el cual tendrá el precio exacto de ese momento, no el que se vaya actualizando con la base de datos.

También tomaré en cuenta ese detalle y haré un histórico de precios como dices.

Muchas gracias a todos por la ayuda!!

smarquezp

Pues finalmente me putean y no voy a poder terminar el proyecto.

Debido a que no se pueden realizar las prácticas del fin de grado superior ahora mismo y se aplazarían a la convocatoria de septeimbre, tampoco puedo realizar el proyecto hasta que haga las prácticas.

Tengo otra opción que sería a la vez de hacer este proyecto, hacer otro proyecto integrador, relacionado con las prácticas. El caso es que no se de donde iba a sacar tiempo para hacer los dos a la vez y creo que me merece más la pena aguantar hasta septiembre, formarme por mi cuenta en este tiempo y finalmente acceder a las prácticas.

Muchas gracias por haberme ayudado de todas formas, nos vemos!

Usuarios habituales

  • smarquezp
  • eXtreM3
  • AddeL1749
  • Runig006
  • cabron