No estoy seguro de cómo decir esto perfectamente, pero déjame intentarlo. Estoy trabajando en la creación de una aplicación de control de inventario que se utilizará con muchos clientes diferentes para hacer todo, desde controlar su stock de artículos, obtener precios, pedir productos, etc. El front-end está en Flex (Flash Builder) y la parte posterior final es MySQL y PHP. Entonces, esta es la verdadera pregunta, supongo. Cuando el cliente realiza un pedido de un producto, no estoy seguro de cuántos de ellos están pidiendo, pero necesito guardar todos los artículos en un solo "boleto". (Ejemplo: una orden podría ser para 2 manzanas, 3 naranjas, una banana y un kiwi). La siguiente podría simplemente pedir una manzana). De modo que en mi base de datos de "tickets" tengo espacio para hasta 20 artículos (ticketItem1, ticketItem2, etc ...) - El inconveniente obvio aquí es que si el cliente solo solicita un producto, me quedan 19 espacios vacíos.¿Está bien tener MUCHOS valores nulos en la base de datos MySQL?
¿Qué tipos de problemas, si los hay, normalmente están asociados con tener muchos valores NULL en una base de datos? ¿Hay alguna manera de ayudar a prevenir que sucedan? ¿Y hay alguna sugerencia para ayudar en esto?
Además y finalmente - Cada artículo ordenado (usemos una manzana de nuevo) tiene su propio código de barras UNICO asociado a él. Entonces, una manzana puede tener el número 0001 y otra puede ser 4524 ...
Gracias por cualquier ayuda que pueda ofrecer.
-CS
¿Por qué no se puede usar una relación 1: n con los pedidos de la tienda y los artículos pedidos? – Maerlyn
Lea sobre [Normalización de base de datos] (http://www.phlonx.com/resources/nf3/). –
No deberías hacerlo de esta manera. Debería agregar otra tabla llamada 'orderItems' o algo así, con la ID del orden en ella, de esta manera usted puede tener infinitos productos por pedido, es mucho más fácil de administrar y está en una elegante relación de uno a muchos. – Bojangles