Cita: Estoy haciendo en PHP una web con tienda online.
Cita: Es para una tienda física cuyo grueso de ventas se realiza en el establecimiento, no en la web.
Creo que tienes que ponerte de acuerdo respecto a lo que estás desarrollando... Bromas aparte.
Más allá de esto, una base de datos para on-line o para un local físico no se diferencia en su diseño en cuanto al manejo de stock, precios, clientes y ventas. Se diferencia porque se requieren más entidades y sus tablas consiguientes, para administrar la operactoria on-line.
REspecto a ua tabla para adminsitrar esepcíficamente las existencias, es básicamente correcto, pero con una salvedad: Conceptualmente, los talles, colores y demás atributos de un producto pertenecen a otra tabla, y no a las exsistencias. Se corresponde a una tabla que usualmente se denomina modelos_productos o algo semejante. Esto es porque son variantes del producto, y no de la existencia del producto base.
Además, poner esos detalles en existencias te obligaría a insertar N registros de un mismo producto, sólo para diferenciar esas variantes... con riesgo de meter dos veces el mismo modelo con diferencias de denominacion en alguna parte. Es más simple definir los modelos del producto en otra tabla.
Una consecuencia de ese planteo es que no desaparecería la necesidad de más de un registro por producto en la tabla de existencias, pero lo simplificaría a tres campos, numéricos todos: id del producto, id del modelo y la cantidad de existencias.
Ese esquema permitiría realizar consultas y reportes eficientes. Poner los demas atributos del modelo en la misma tabla tiene el potencial de generar inconsistencias de datos si la denominación entra manualmente, cosa que siemrpe hay que evitar.
¿Se entiende?
En esencia, hay que normalizar un poco más para proteger la consistencia de datos y simplificar el uso de la carga de las existencias en la aplicación. La hace más compleja, pero luego el manejo de las ventas tiene consultas más eficientes.