SQL Server - Master de Productos de diferentes clases

Esta no es una consulta puntual del SQL Server. 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

Yo consideraría, a grosso modo, cuatro tablas:

* Tabla de Grupos, donde se define cada grupo.
* Tabla de características, una tabla donde se define cada posible característica por grupo, tipo de dato, rango de valores a aceptar, etc. Una especie de Metadatos.

* Máster de partes, donde va cada artículo con sus características generales. Cada artículo debe ser de un grupo específico.
* Detalle de partes. Para cada artículo del Máster, define sus características particulares tomando como plantilla la Tabla de características del grupo al que pertenezca el artículo.

Muy interesante.... Me gusta.... Haver como sería:

tbl_Grupos (IDGRUPO, DESCRIPC):
1, "Componentes electrónicos"
2, "Gabinetes plásticos"

tbl_Grupo_Características (IDCARACT, IDGRUPO, CARACT, TIPODAT):
1, 1, "Encapsulado", "VARCHAR"
2, 1, "Tension", "VARCHAR"
3, 1, "Potencia", VARCHAR"
4, 2, "Medidas", "VARCHAR"

tbl_Master (IDPARTE, DESCGRAL, IDGRUPO)
1, "Resistencia 1ohm 5%", 1
2, "Case para semáforo", 2

Aquí es donde me quedo... Me faltaría ver como definir la tabla o tablas para los detalles de las partes...

tbl_Partes_Detalles (IDPARTE, IDCARACT, VALOR)
1, 3, "1/4 W"
2, 4, "diám: 200mm"

esa puede ser no?

Creo que así cierra bien.... Lo tengo que pensar un poco más, pero eso sería lo que me recomiendas?

Saludos!

Has captado la idea :)

El caso es que puedas definir entidades polimórficas y sin embargo plenamente compatibles con un esquema de tablas.

Cuando crezcan las necesidades de información, todo estará en tablas, los cambios en los programas serán mínimos.

Ahora sí, asegúrate que tu programa de interfaz interprete correctamente todas las características de grupo para permitirte un ingreso de datos inteligente.

Bien, si no es molestia quisiera pasarte el diseño de las tablas con sus relaciones para estar seguro de estar en lo correcto. Hay una especie de relaciones "cirulares" que no me convence.

Por otra parte, el front end está hecho en visual basic 6. hace años que programo en él y me cuesta despegarme. Debería hacer formularios dinámicos para la carga de informacion, verdad? o sea, si quiero cargar datois de un grupo el formulario debería mostrarme controles que permitan dicha carga, se debe crear en tiempo de ejecucion. Correcto? Podrías sugerirme algún lugar en dónde buscar algunos ejemplos de este tema?

Gracias!