Mostrar en tabla html un registro de una tabla mysql y varios de otra tabla mysql

[0o_shelak_o0]

buenos días a todos, estoy haciendo una web que lleva un inventario de artículos,

y los muestro de la siguiente forma:



bueno os pongo un poco en situación:

-un articulo puede estar en "0" o varias cajas .
-una caja puede tener 1 o varios artículos.

la forma de mostrarlo en la tabla es haciendo una consulta de los artículos y cuando hago el while para mostrar los artículos, dentro de el, hago la select a cajas con el código del articulo y muestro las cajas.

las tablas y sus relaciones son estas:



bueno el listado lo muestro correctamente, pero el problema que tengo es al intentar ordenar por cajas, al ser una consulta diferente sin haberla relacionado con artículos, solo me ordena las cajas del articulo que la corresponde, es decir que si el articulo 1 tiene las cajas 5,2,6 y el articulo 2 tiene las cajas 7,3 me ordena de esta forma

- articulo 1 caja 2,5,6
- articulo 2 caja 3,7

y necesito que me lo haga de la siguiente manera:


caja 2
articulo 1

caja 3
articulo 2

caja 5
articulo 1

caja 6
articulo 1

caja 7
articulo 2


espero haberme explicado bien y si coneceis alguna otra forma de mostrar los resultados en una tabla, os lo agradecería mucho.

un saludo

[gnzsoloyo]

En lo que a SQL se refiere, sólo puedes hacer eso con una consulta que relacione ambas tablas.
El resto es tema de la aplicación, y fuera del alcance de MySQL.

[0o_shelak_o0]

me lo podrías mover a php, por favor? a ver si alguien me puede dar una pista de como hacerlo.

gracias

[gnzsoloyo]

Antes, quisiera hacer algunas aclaraciones, porque me parece que hay un problema con el modelo de datos que muestras, y con lo que expresas de la relación Caja-Artículo.

Según lo que pones, el modelo de datos que tienes es:

Ahora bien, en la tabla artículos, me parece ver que la PK es una clave compuesta de IdArticulo y CodArtículo, lo que a mi entender es incorrecto, si IdArticulo fuese un autoincremental. O usas uno, o usas el otro como PK, pero compuesta... puede prestarse a errores de inserción (Podrías ingresar N veces el codigo de articulo, sin que dispare errores).
Por otro lado, dices:

-un articulo puede estar en "0" o varias cajas .
-una caja puede tener 1 o varios artículos.

Eso es una relación N:M y obligatoriamente requiere una tercera tabla. No la peudes evitar, porque de lo contrario no puedes cumplir con esa relación. Es un requerimiento del modelo E-R.
¿Eso lo tienes? ¿Lo consideraste?

[0o_shelak_o0]

buenas gnzsoloyo, la relación de las tablas es idArticulo la PK autoincremental, y el códigoArticulo que es el que se relaciona con el codigoCaja.

lo que comentas de N:M no lo había contemplado, que debería ir en esa tercera tabla?

-------------------------EDITO----------------------------

vale la tercera tabla guardaría la relación entre una tabla y otra no?

de esa forma con usar en articulos una de las 2 claves bastaria..

un saludo y gracias

[gnzsoloyo]

Toda relación N:M obligatoriamente crea una tabla relacional, tal que la tabla contenga por columnas al menos las PK de cada una de las tablas relacionadas, y ambas claves compongan la PK de esa tabla.
Sólo requieren columnas adicionales si puede haber más de una instancia de esa tabla para el mismo par de claves, y en ese caso esa/s columnas adicionales o al menos una d eellas debe ser un discriminante, y parte de la PK.

¿Conoces mas o menos en profundidad el modelo Entidad-Relación y su aplicación en las bases de datos relacionales?

la relación de las tablas es idArticulo la PK autoincremental, y el códigoArticulo que es el que se relaciona con el codigoCaja.

La relación entre dos tablas se determina con la clave primaria (PK) de una de ellas en la otra tabla, como FK. Pero tu estás poniendo como PK de la tabla artículos dos campos al mismo tiempo, lo que implica que es una clave compuesta. O usas el Código, o usas el IdArticulo, pero no ambos a la vez.
En tu contexto, podría existir un mismo código de producto combinado con diferentes IDArticulo, porque el idArticulo nunca se repite, y el CodArticulo si.
Es decir, si la clave es (idArticulo, CodArticulo), un conjunto de inserciones tales como:

Código SQL:

(1, 34)
(33, 34)
(128, 34)
(1429, 34)
 

es perfectamente válido, porque el primer campo no se repite.
¿Se entiende?
Además, siendo que una FK se define como un campo o conjunto de campos que referencia a la PK de otra tabla, la segunda tabla (cajas) está mal, porque no contiene el par relacional (violacion severa a la normalización de BBDD).
¿Se entiende?

todo esto te traerá problemas de consistencia de datos y de integridad referencial. Y de los grandes.

[0o_shelak_o0]

muchas gracias gnzsoloyo, voy a echar un vistazo, y estudiar mejor el modelo E-R

[0o_shelak_o0]

hola otra vez... esto seria lo correcto?

[gnzsoloyo]

Va mejor...

Me aparecen algunas dudas respecto a lo que planteas, porque veo información que parece redundante...
¿Por qué la tabla Barcode y la Articulos tienen ambas idénticos campos "precio" y "precioNuevo", "ventas, Cantidad", y "unidadesTienda"?
¿Existe alguna diferencia puntual entre los datos que contendrán ambas tablas para el mismo artículo?

[0o_shelak_o0]

Iniciado por gnzsoloyo

Va mejor...

Me aparecen algunas dudas respecto a lo que planteas, porque veo información que parece redundante...
¿Por qué la tabla Barcode y la Articulos tienen ambas idénticos campos "precio" y "precioNuevo", "ventas, Cantidad", y "unidadesTienda"?
¿Existe alguna diferencia puntual entre los datos que contendrán ambas tablas para el mismo artículo?

la función de la tabla barcode es, que cada x tiempo hay que devolver x artículos, y seria como un "listado" llamemoslo así, para saber lo que hay que devolver.

supongo que se podría sacar los datos de artículos y cajas sin tener que almacenar 2 veces los mismos datos no?

se podría evitar esa tabla añadiendo un campo mas a artículos?

[gnzsoloyo]

supongo que se podría sacar los datos de artículos y cajas sin tener que almacenar 2 veces los mismos datos no?

Precisamente. Eso que planteas es lo que se denomina un riesgo de consistencia de datos.
Si por alguna razón (imprevisible en una aplicación web), pueda darse un problema de sincronización entre los datos de ambas tablas, la información contenida podría ser incorrecta en una de ellas. Ese es un riesgo que no se debe corrrer.

Si la tabla "Barcode" es una tabla que guarda transacciones temporales sobre los productos, eso habría que diseñarlo de otro modo. Además que no se debe poner información que no le pertenezca.
Es decir, si debes volver al stock una cantidad de N unidades de un articulo, lo que corresponde es guardar sólo la cantidad a devolver, y no el precio que tiene.
Otra cosa, no obligatoria, pero sí conveniente, es que los nombres de las tablas sean representativos de lo que son esas tablas. Un "barcode" es un código de barras, y en ningún modo se relaciona con un stock transaccional o de devoluciones de mercadería. Son conceptos diferentes.

[0o_shelak_o0]

Iniciado por gnzsoloyo

Precisamente. Eso que planteas es lo que se denomina un riesgo de consistencia de datos.
Si por alguna razón (imprevisible en una aplicación web), pueda darse un problema de sincronización entre los datos de ambas tablas, la información contenida podría ser incorrecta en una de ellas. Ese es un riesgo que no se debe corrrer.

Si la tabla "Barcode" es una tabla que guarda transacciones temporales sobre los productos, eso habría que diseñarlo de otro modo. Además que no se debe poner información que no le pertenezca.
Es decir, si debes volver al stock una cantidad de N unidades de un articulo, lo que corresponde es guardar sólo la cantidad a devolver, y no el precio que tiene.
Otra cosa, no obligatoria, pero sí conveniente, es que los nombres de las tablas sean representativos de lo que son esas tablas. Un "barcode" es un código de barras, y en ningún modo se relaciona con un stock transaccional o de devoluciones de mercadería. Son conceptos diferentes.

- ¿entonces dices que lo conveniente seria guardar solo en esa tabla las unidades a devolver? ¿o lo harías de otra forma?

- lo del nombre "barcode" es porque lo llamamos así al proceso de preparar los productos para devolverlos. pero tienes razón lo normal seria poner devolución en el nombre de la tabla, por que alguien que modifique esa tabla no tiene porque saber que el proceso ese se llama "barcode".

[gnzsoloyo]

Iniciado por 0o_shelak_o0

- ¿entonces dices que lo conveniente seria guardar solo en esa tabla las unidades a devolver? ¿o lo harías de otra forma?

Exacto. Sólo la información referida a la devolución, ya que es la única información relevante.
Por supuesto que hay tantas formas de diseñar las devoluciones desde tiendas hasta la central, como sistemas administrativos existen en el mundo (en una empresa que trabajé, esa devolución implica afectar más de sesenta tablas).
Ahora bien, si el envío de artículos a las tiendas implica documentos de venta interna, o cualquier asiento contable, esos asientos también deben revertirse. Y eso es un universo entero de procesos.

Iniciado por 0o_shelak_o0

- lo del nombre "barcode" es porque lo llamamos así al proceso de preparar los productos para devolverlos. pero tienes razón lo normal seria poner devolución en el nombre de la tabla, por que alguien que modifique esa tabla no tiene porque saber que el proceso ese se llama "barcode".

Es conveniente no confundir procesos con modelos de datos. Son cosas completamente diferentes. No se analizan ni se razonan de la misma forma. Y no es broma.
Para decirtelo en pocas palabras, los repositorios de datos alimentan a los procesos, pero no son definidos por los procesos. Los modelos de datos se deben crear de tal forma que puedas cambiar de aplicación sin tener que modificar la base de datos.
Esa sí es una regla universal.