2011-10-05 19 views
6

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

+0

¿Por qué no se puede usar una relación 1: n con los pedidos de la tienda y los artículos pedidos? – Maerlyn

+2

Lea sobre [Normalización de base de datos] (http://www.phlonx.com/resources/nf3/). –

+1

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

Respuesta

7

En lugar de tener 20 columnas ticketItem1, ticketItem2, ..., introducir una tabla order_item, así:

Tabla fin:

id customer 
1 42 
2 23 

Tabla elemento:

id name 
1 banana 
2 kiwi 
3 apple 
4 oranges 

Tabla order_item:

order_id item_id multiplicity 
1  1  1    # 1 banana 
1  2  1    # 1 kiwi 
1  3  2    # 2 apples 
1  4  3    # 3 oranges 
2  3  1    # 1 apple in the second order 

artículos Entonces, JOIN sobre las mesas para conseguir todos ordenados en un orden.

1

Usted debe tener una tabla que muestra la Orden, y uno de los OrderDetails con un IdPedido apuntando a la tabla Order

Así que si usted tiene 10 productos en una orden. Tendrá 1 fila en orden, y 10 en OrderDetails

+0

Por lo tanto, si entiendo esto correctamente, aún tendré muchos valores nulos, solo aparecerán en una tabla separada que indica qué producto específico se solicitó para ese 'ticket'. ¿Cuál es el beneficio de hacerlo de esta manera versus el otro? - Leeré más sobre la normalización de DB también. Sin embargo, habrá ~ 30-50 pedidos/boletos por día ... ¡Agradezco la ayuda! –

+0

No realmente. Tienes 1 tabla que enumera todo el orden, sin las entradas. Tiene, por ejemplo, en esta tabla las siguientes columnas: Id., Fecha de pedido, IsProcessed y en otra tabla Artículos de pedido: Id., Id. De pedido, Boleto y cualquier otra columna para información específica de 1 boleto. Si tiene un pedido con 20 boletos. Tendrás 1 entrada en la tabla Órdenes y 20 entradas en Detalles de la orden. Y no habrá valores NULL en ninguna columna – Frank

0

Si quiere ser dinámico en lo que almacena, podría usar una matriz json. Estoy completamente de acuerdo con los demás en que la normalización de la base de datos es lo primero. Seguiría las reglas de Codd.

Pero en caso de que no sepa exactamente lo que necesita para almacenar json podría ser una solución. Uno importante inconveniente sin embargo es que la búsqueda se está poniendo bastante difícil.

Cuestiones relacionadas