Por favor necesito ayuda con esto
cucu
17 de Febrero del 2006
Estoy haciendo un programa que tiene la siguiente particularidad: Es para un negocio que vende repuestos de maquinas, entonces pense en una tabla para almacenar los repuestos, pero en realidad dependiendo del proveedor el repuesto va a tener mas o menos campos, es decir, se puede dar el caso de que un repuesto tenga 7 campos, otro con 5, otro con 9 y asi. No se sabe con anticipaci贸n la cantidad de campos que va atener un repuesto.
Una de las cosas que se me ocurrio es que al ingresar proveedores, indique la cantidad de campos que tienen los repuestos que vende el proveedor. El problema es que tengo duda de c贸mo almacenar los repuestos. Se me ocurrieron estas dos maneras:
1) Tener una tabla 聭repuestos聮 con 20 campos, pero los problemas con esto es que voy a ingresar registros que no lleguen a completar los 20 campos y van a estar muchos campos en blanco por cada registro que tenga y otro problema es que si aparece un proveedor que venda repuestos con mas de 20 campos para las especificaciones no se podran ingresar.
2) Tener dos tablas, una 聭erpuestos聮 y la otra 聭carat聮 , entonces cuando ingreso un registro tendria que consultar en la tabla 聭proveedores聮 para saber cuantos campos de caracteristicas tiene el repuesto. Por ejemplo si tengo que ingresar un repuesto con 5 caracteristicas, en la tabla 聭repuestos聮 voy a ingresar el codigo y el precio del repuesto y en la tabla 聭caract聮 voy a ingresar 5 registros que sean las 5 caracteristicas del repuesto.
Me gustaria saber cual de las 2 me conviene mas. Teniendo en cuenta que son mas de 10000 repuestos y tengo que poder hacer consultas o si a alguien se le ocurre como solucionar este problema o que me de alguna idea se lo voy a agradecer. Tambien me gustaria saber si mysql se banca tanto registros.
Desde ya muchisimas gracias.
Una de las cosas que se me ocurrio es que al ingresar proveedores, indique la cantidad de campos que tienen los repuestos que vende el proveedor. El problema es que tengo duda de c贸mo almacenar los repuestos. Se me ocurrieron estas dos maneras:
1) Tener una tabla 聭repuestos聮 con 20 campos, pero los problemas con esto es que voy a ingresar registros que no lleguen a completar los 20 campos y van a estar muchos campos en blanco por cada registro que tenga y otro problema es que si aparece un proveedor que venda repuestos con mas de 20 campos para las especificaciones no se podran ingresar.
2) Tener dos tablas, una 聭erpuestos聮 y la otra 聭carat聮 , entonces cuando ingreso un registro tendria que consultar en la tabla 聭proveedores聮 para saber cuantos campos de caracteristicas tiene el repuesto. Por ejemplo si tengo que ingresar un repuesto con 5 caracteristicas, en la tabla 聭repuestos聮 voy a ingresar el codigo y el precio del repuesto y en la tabla 聭caract聮 voy a ingresar 5 registros que sean las 5 caracteristicas del repuesto.
Me gustaria saber cual de las 2 me conviene mas. Teniendo en cuenta que son mas de 10000 repuestos y tengo que poder hacer consultas o si a alguien se le ocurre como solucionar este problema o que me de alguna idea se lo voy a agradecer. Tambien me gustaria saber si mysql se banca tanto registros.
Desde ya muchisimas gracias.
nuncataxi
17 de Febrero del 2006
Estimado cucu.
La segunda solucion es la que se acerca mas a la "verdad", pero te recomiendo que hagas un ciclo mas en el diseño de la bd. Normalizando, encontraras la solucion.
Sin que informes cual es la utilidad de mantener los 20 o 39 o 59933 campos por cada repuesto, no tiene sentido que te aconseje algo, pero Dios odia al cobarde y aqui vamos.
Seguramente hay campos que si o si deben pertenecer a la tabla en cuestion, luego tienes atributos que son (claves de busqueda ? , caracteristicas distintivas ?, codigos propios de proveedores ?, etc.... no se, se me ocurren mil cosas) datos que simplifican la busqueda u orientan al vendedor al tiempo de venta y al comprador al tiempo de reposicion. Eso lo haces normalizando una tabla que tenga como clave la del producto y un campo mas (que puede ser un smallint) donde registras la info que consideras anexa ( codigo del proveedor, forma, lo que cuernos sea) que puede ser a su vez normalizada con un codigo de caracteristica (el cual puede o no estar asociado con el proveedor que lo genera) o bien directamente una descripcion fisica (un texto normalizado donde ALT xej. signifique altura, FRM forma, etc.) y luego generas sobre ese campo una busqueda por ocurrencia.
Esto es tratar de volar bajo por instrumentos (no se cual es el problema en si y no puedo darte mas info) asi que si continuo, vamos a chocar con algo.
Espero tus comentarios para poder darte alguna mejor solucion.
Sls.
Hg.
La segunda solucion es la que se acerca mas a la "verdad", pero te recomiendo que hagas un ciclo mas en el diseño de la bd. Normalizando, encontraras la solucion.
Sin que informes cual es la utilidad de mantener los 20 o 39 o 59933 campos por cada repuesto, no tiene sentido que te aconseje algo, pero Dios odia al cobarde y aqui vamos.
Seguramente hay campos que si o si deben pertenecer a la tabla en cuestion, luego tienes atributos que son (claves de busqueda ? , caracteristicas distintivas ?, codigos propios de proveedores ?, etc.... no se, se me ocurren mil cosas) datos que simplifican la busqueda u orientan al vendedor al tiempo de venta y al comprador al tiempo de reposicion. Eso lo haces normalizando una tabla que tenga como clave la del producto y un campo mas (que puede ser un smallint) donde registras la info que consideras anexa ( codigo del proveedor, forma, lo que cuernos sea) que puede ser a su vez normalizada con un codigo de caracteristica (el cual puede o no estar asociado con el proveedor que lo genera) o bien directamente una descripcion fisica (un texto normalizado donde ALT xej. signifique altura, FRM forma, etc.) y luego generas sobre ese campo una busqueda por ocurrencia.
Esto es tratar de volar bajo por instrumentos (no se cual es el problema en si y no puedo darte mas info) asi que si continuo, vamos a chocar con algo.
Espero tus comentarios para poder darte alguna mejor solucion.
Sls.
Hg.