Cita: ¿Diseño una tabla adicional para cada tipo de artículo con sus campos correspondientes además de una general y las relaciono con la tabla con los campos comunes?. En este caso, ¿cómo se en qué tabla están los campos concretos para un artículo almacenado en la primera tabla?.
No hay una regla fija sobre lo que debe hacerse con los "datos adicionales" de un producto. Depende mucho de qué datos son, y para qué se usarán. Sí, en caso de precisarse, se recomienda analizar los datos que puedan definirse como comunes, aun ante productos distintos.
Por ejemplo: Volumen, longitud, peso, etc, pueden ser valores conceptualizados como "presentación", y el tipo de medida, ser definido como un atributo ENUM, por ejemplo. Eso evitará tener que definir múltiples campos para una misma idea base, y le aportará flexibilidad como para usar sólo dos columnas para gestionar cuatro o cinco tipos de unidades de medición distintas.
Por regla general, no se almacenan datos que no vayan a tener uso al momento de la venta, por lo que si lo que varía es el color del empaque, el papel de las etiquetas, o cosas así, no son muy relevantes.
Además, si todos los productos tienen su código de barras, es muy probable que esa información ya exista dentro de una base de referencia de los mismos, ya que si te fijas, el mismo producto, en sus diferentes presentaciones, colores, etc, tienen diferentes números de código de barra. Incluso si fuesen libros, el ISBN ( su correspondiente EAN) cambian dentro de la misma editorial, para el mismo libro, y en la misma edición, si el tamaño del libro es distinto (se debe registrar uno diferente por cada tamaño).
Con esto quiero decirte que debes acotar la información a lo realmente relevante. A lo que se usará, y luego el tema de los precios se administra por código de barras, no por sus descripciones.