MySQL - Master de Productos de diferentes clases

Esta no es una consulta puntual del mySQL . Pero aplica.
En mi empresa creamos productos electrónicos. Los fabricamos y vendemos. Cada producto está compuesto or diferentes elemenros. Componentes electrónicos, tornillos, carcazas plásticas, pegamento, etc.
Estoy armando el sistema completo de administracion de mi empresa y necesito llevar el stock de los componentes de cada producto. Incrementar los mismos al comprar y decrementar los mismos al vender un producto.
El tema es que estoy entre hacer un solo master de componentes universal el cual incluya características generales de cada clase de componente o, me gustaría más, poder almacenar cada componente con sus características particulares en tablas separadas y luego vincularlas a los productos. El problema es que si tengo mucha clases de partes que constituyen un producto voy a tener muchas tablas y el hechco de agregar nuevas clases de partes cuando mi empresa crezca implicará agregar más tablas. como ventaja tengo que puedo definir cada parte con las características propias de esa parte (no tienen igualkes propiedades los tornillos que los componentes electrónicos). En cambio si hago iuna tabla universal y meto todo allí, pongo solo un ID y una descripcion tengo la ventaja de que en una tabla tengo todo, pero me pierdo de poder filtrar la informacion.
Por otra parte tengo proveedores que me venden las partes y que debo vincular entre sí.

Alguien me puede decir que es lo que se suele utilizar? Una sola tabla tipo master de partes o un grupo de tablas por cada clase de parte que tenga mi producto?

Saludos

Lo que tienes que hacer es dos cosas:
1) Estudiar bases de datos, porque saber trabajar en POO no implica que entiendas el modelo E-R de bases de datos y estás cometiendo errores conceptuales severos que te traerán problemas gavísimos en el futuro.
2) Documentarte con modelos resueltos que te puedan ayudar, en el caso de no querer estudiar el tema. Te recomiendo:
- http://www.databaseanswers.org/data_models/
- http://www.databasedev.co.uk/data_models.html

Bueno, he investigado un poco más y me he topado con dos nuevos conceptos para mí en bases de datos. Herencia y jerarquía. Lo vi en el tutorial de database answer y lo investigue un poco en la web. Más o menos ya entiendo el uso.
El tema es que no creo que resuelva mi problema, ya que estamos hablando de que cada clase de parte posee características distintas....
Estoy cerca de resolverlo, pero aún me quedan dudas....

Gonzalo, creeme que conozco bastante de bases de datos relacionales. Hace años que hago "pequeños" programas y no tan pequeños en VB usando como base de datos sql server o mysql.
El tema es que con este tema puntual de hacer un master de partes de cosas distintas a las cuales aplican acciones similares nunca supe como resolverlo o mejor dicho, cual es la forma "normal" de resolverlo. Creo que no hay que inventar nada, ya muchos lo deben haver resuelto y es por ello que pregunto si alguien sabe como se resuelve, en la teoría, este tema.
en: http://www.lawebdelprogramador.com/news/1255487/Master_de_Productos_de_diferentes_clases.html me han tirado una idea y la estoy elaborando.
Libros de bases de datos relaciones he lido un par, pero ninguno ha abordado este tema, ya que pasa por el programador imagino.
Las libreías de ejemplos que me pasaste están geniales!!!! aunque sinceramente, me gustaría discutir la teoría de como resolver mi problema.
Por si no lo expresé de forma correcta el tema es así:
Fabrico productos, los prodctos están formados por partes, las parte tienen diversas características y existen grupos de ellas. Quiero llevar el stock de los productos y de las partes. Quiero poder cargar las partes que constituyen un producto.
Hasta ahora tengo funcionando tdo esto, pero solamente con el grupo de partes "Componentes electrónicos" ya que era lo único que quería almacenar, hasta que mi socio bino y me dijo y si añmacenamos todo lo que constituye un producto? de esa forma tendremos el control de stock de todo lo necesario para armar un producto.... y me cagó el fin de semana largo....
Bueno, gracias por tu respuesta y espero me ayudes un poco más, si conoces algún ebook en donde se aborden estos temas teóricos de bases de datos relacionales te estaría agradecido, me gustaría leer un poco....

Gracias!

mmm yo me encontre con algo asi y se resuelvo con los conseptos de "tipos-subtipos"
pero te lleva alo mismo, tener una "super clase" que son los campos que comparten todos ejemplo catgoriadelproducto,nombredelproducto,marca etc.
La pregunta es si es totalmente necesario especificar la particularidades de cada producto, por que me imagino que deben ser varios y por no decir N, lo que implicaria que cada vez que incorpores un nuevo producto tendras que desarrollar toda una entidad para este.
La otra es crear una tabla donde puedas crear y campos para producto en tu catalogo ejemplo:

idproducto_FPK INT,IdCAmpoPK,NombreCampo,Valor

Ejmeplo


1 - 1 - Watts - 450
1 - 2 - InputVolts - 220
2 - 1 - Peso/Grs - 500

el cod 1 puede ser una fuente de PC y el 2 un paquete de fideos.

con lo cual generas campos en "tiempo de ejecucion" y tendras que en tu aplicacion escribir algun algoritmo que si eligen este tipo de productos permita leer los campos y permitir filtrarlos por esos ampos especificos de ese producto.

NO veo algo simple en esto, yo evaluaria los costos de desarrollo etc y ver si la empresa realmente podra costearlos, tene en cuenta que tambien implica que el software sera mas complejos para usar.

SAludos.

Martín, gracias por tu colaboracion.
Estuve casi todo el día leyendo info sobre este tema y no consigo que alguien diga la forma "estándar" de resolver esto. Muchos plantean el problema, pero no veo la solucion. Algo bueno que encontré es:
http://www.databaseanswers.org/tutorial4_db_schema/tutorial_slide_8.htm
Ahí se plantea el problema y 3 posible soluciones, pero no se argumenta esas soluciones.
También encontre:
http://geynen.wordpress.com/2010/11/18/jerarquia-de-datos-con-sql-server/
que es una implementacion práctica de como hacer jerarquía de partes.
Lo que tu dices es cierto, hacer alg perfecto es muy complejo y costoso. Si bien no puedo sacarme de la cabeza la pregunta "como se resuelve esto?" (soy ingeniero y siempre quiero saber como se resuelven las cosas), no puedo gastar mucho tiempo en esto.
Creo que por ahora simplemente voy a tener 3 tablas:
tbl_Partes (IDParte, Descripcion)
1, BC807
2, 5ohm
3, gabinete semaforo
4, 220uF

tbl_Caracteristicas (IDCaract, Descripcion)
1, Tension de trabajo
2, Medidas
3, Potencia
4, Encapsulado
5, Tipo de rosca

Luego las vinculo con otra tabla

tnl_Partes_Caracteristicas (IDparte, IDCaract, Valor)
1, 4, "TO-92"
4, 1, "50V"
2, 3, "1/4W"
2, 4, "2x4mm MINI"

de esta forma puedo almacenar y las características de cada componente a gusto.
Hay un tema que no resuelve. Todas las resistencias poseen las misma características, pero de esta forma no puedo saberlo y cada vez que cree una resistencia debo cargarle que características le corresponen.
Pensé en poner un camo de Grupo en la tablas de Partes para crear grupos de características, pero creo que volvería a complicar las cosas....

Una cosa, la jerarquia de las parte tendría solo 2 o 3 niveles estimo, el tema es que en cada nivel o cada sub clase tiene características totalmente diferentes a las otras subclases.... Mi cerebrito no me da para pensar en la solucion más elegante....

Espero más opiniones de los expertos!!!!