dudas para comenzar proyecto

[gralf]

Y muchas.

Hola, soy nuevo aquí, tengo algunos conocimintos de mysql pero no demasiados, pretendo crear una db para controlar un stock de lentes y la verdad me asaltan demasiadas dudas.

Os cuento un poco

Tenemos varios tipos de lentes, pueden ser unos 15 diferentes, cada lente puede tener una graduacion, ahi tenemos un importante numero de diferentes opciones, por ejemplo, un lente 1.49hc puede tener graduacion desde -4.00 esf -2.00 cil hasta +4.00 esf 0.00 cil y estas grduaciones se mueven de 0.25 en 0.25; con lo que por ejemplo las graduaciones irian....

-4.00 esf -2.00cil,-4.00 esf -1.75cil, -4.00 esf -1.50cil,-4.00 esf -1.25 cil,-4.00 esf -1.00 cil....... y asi hasta 0.00 cil, momento en que bajariamos a -3.75 y el cilindro comenzaria de nuevo en -2.00 para ir bajando. No se si se entiende bien.

Tenemos varios lentes de cada graduacion y lo que pretendo es hacer un stock para controlar entradas salidas y asi optimizar las reposiciones.

Me parece que una tabla tipo lentes y otra graduaciones seria el primcipio, os parece correcto?

[gralf]

empiezo a pensar que igual este no es el mejor sitio para este post, algun moderador sería tan amable de moverlo a BDs general??.

gracias y siento las molestias

[David_Carrera_G]

Yo creo que si lo quieres realizar en MYSQL puede ser el lugar correcto, estimado según como describes el negocio el tema de los lentes seria tan fácil como crear una tabla la cual pueda almacenar las características de cada lente y otra tabla que pueda almacenar la graduación con las cuales vas a trabajar. Al menos así abordaría lo que especificas en el comentario.

[gralf]

una tabla para cada tipo de lente y otra con las diferentes graduaciones, eso es? y para cada cantidades, entradas, salidas y eso?

[David_Carrera_G]

Iniciado por gralf

una tabla para cada tipo de lente y otra con las diferentes graduaciones, eso es? y para cada cantidades, entradas, salidas y eso?

Claro de esa forma podrías gestionar de buena forma cada lente y sus respectiva graduación, para el tema de las cantidad este yo lo abordaría en una tabla diferente, en la cual controlaría las cantidades en stock, salida y entrada de productos, según mi visión esto debería quedar algo así:


GRADUACIÓN -----> con relación hacia PRODUCTO(lentes) ----> con relación hacia
STOCK_PRODUCTOS.

Ahora todo esto depende si la graduación(cristales) existe aparte de los lentes(marcos, según yo), osea dos productos separados que se venden como un solo producto. Hay tendríamos que controlar tanto el stock de los cristales, como el de los marcos y cambiaría el modelo. Saludos

[solmedina87]

En principio está bien lo que planteás, sería una tabla con los productos (lentes) y otra con graduaciones.
Para mi habría que tener una tercer tabla que relacione 1 lente--> n Graduaciones.
De esa forma podrías tener:
lente 1 --> graduación 1
lente 1 --> graduación 2
lente 1 --> graduación 3
lente 2 --> graduación 1
lente 2 --> graduación 4

[gralf]

una cuestion que me surje es

como tengo diferentes tipos de lentes, y cada uno de ellos tiene un rango de graduaciones, y no son iguales por cada tipo, aunque en algunos se solapan, no se si me explico, quiero decir

por ejemplo el 1.4 va de -4 a +4, pero el 1.6 va de +6 a -6 (lo cual incluye tambien el -4 a +4) que sería lo mejor, una tabla con cada rango para cada tipo de lente o una tabla con el rango de graduaciones mas amplio y de ahí cada lente usar el adecuado?


por cierto adjunto sql de la tabla lentes

https://www.dropbox.com/s/arateeo0io0r3ff/lentes.sql?dl=0

[David_Carrera_G]

Al menos yo lo trabajaría por separado, una tabla con lo mencionas(el aumento +4 - 4).

AUMENTO ---> LENTES ----> GRADUACIÓN ----> STOCK_PRODUCTOS

[gralf]

lo siento pero no entiendo lo que quieres decir

añado el sql de la tabla lentes

http://www.filedropper.com/lentes

[David_Carrera_G]

Si nos adjuntas más información sobre tu problemas, como una descripción un poco más explicativa del negocio, quizás podamos dar una mejor observación. Saludos.

[gnzsoloyo]

A mi entender el problema que tienes es que estás mirando los detalles de los productos en lugar de hacer una abstraccion de los mismos y tratar de deterimar las características de las entidades que los contienen.
Antes de proceder a diseñar tablas y relaciones debes definir los objetos que contiene ese sistema y a partir de ellos definir cuales son los atributos que poseerán las entidades en un modelado relacional que las pueden incluir.

Si sigues pensando en los valores de los datos, en lugar de los datos como atributo, se volverá confuso.

Lamentablemente no tenemos un subforo dedicado al analisis de sistemas, que es el punto debil de todo este caso que describes, sino movería el post para alla.

En lo que parece ser, hay que definir algunas cosas:

- Qué atributos son propios de los Lentes como abstracción, es decir ¿qué atributos son comunes a TODOS los lentes?

- Qué Tipos de Lentes existen y en qué se diferencian. Esto determinará una cosa: Si no existen atributos que los diferencien, y sólo se diferencian en el uso que se da al lente fisicamente hablando (el objeto tangible), entonces los tipos no son parte del modelo de datos, sino del proceso de la aplicacion.
Pero si los tipos muestran una o más diferencias de atribuitos que son propios de uno u otro tipo, entonces la Entidad Lente puede tener una relacion con otra de Tipos de Lente, o bien existe una jerarquia de herencia, lo que implica que Lentes compondrá más de una tabla.

- ¿Qué es una graduación y en qué atributos se descompone? Cuando haces la descripcion de los valores pareces describir ciertos rangos de magnitudes quese usan respecto de un lente. Lo que edbes definir es qué describe cada magnitud y cuantas se necesitan para describir una sola graduacion.

- Si una graduación aplica a un único tipo de lente, la propia tabla degraduaciones (de necesitar existir) podría relacionarse con el tipo de lente sea en forma directa como transitiva. Hay que definir mejor eso.
Pero si una misma graduacion (con todas sus magnitudes) sólo apolica a un único tipo de lente, entonces es probable que las graduaciones sean parte de los atributos propios de Lente. Sólo se justificaría que graduaciones sea una tabla aparte si se forman conjuntos repeteitivos de magnitudes entre dos lentes diferentes.

- Finalmente, el stock apunta a una relacion de todos los elementos en un único registro. Pero para definir esa relacion hay que primero definir lo previo.

Nota bene: No confundas los valores que una graduación tiene, con los atributos que componen la graduación. A nivel de diseño bases de datos, los valores no existen, sólo existen los dominios que implica el rango de representacion que un mismo atributo tendrá.
Los valores que un registro contenga son propios de la instancia (registro físico), y no parte del modelado.

¿Se entiende?

Trata de describir los elemntos que te digo de un modo más abstracto. de ese modo te acercarás mejor a la estructura correcta de la base que necesitas. No te pierdas en los detalles.

[gralf]

muchas gracias por tu respuesta. a ver si soy capaz de explicar un poco esto.

tengo diferentes tipos de lentes, vease el sql que he adjuntado arriba, que no se como poner el codigo aqui en la ventana de edicion.

voy a resumir en dos lentes aunque ya veis que hay mas.

1.49 hc , es un lente con un indice, un numero de abbe, una densidad y una geometria y un nombre mas cmpleto (para explicar las iniciales HC) todo ello lo he puesto en la tabla lenes, son datos invariables, quiero decir 1.49 hc tiene su abe, su dens, su geom y su nombre.

despues de esto cada lente puede tener una graduacion, las graduaciones vienen dadas por un cilindro y una esfera;

el cilindro en el caso del 1.49 va de -2.00 a 0 en pasos de 0.25 dioptrias, -2.00, -1.75,-1.50, -1.25, 1.00, -0.75, -0.50, -0.25, 0.00

en otros lentes el cilindro puede comenzar por ejemplo en -4.00 y llegara 0.00 del mismo modo.

la esfera pues es igual, lo único que abarca más dioptrías, por ejemplo en el aso que nos ocupa, el 1.49 va de -4.00 a +4.00, o sea -4.00, -3.75.......0.00, +0.25, +0.50.....+4.00

en otros lentes el rango es mayor, por eejmplo de -8.00 a +8.00.

la graduacion total del lente viene dad por la combinacion esfara cilindro, por ejemplo

-2.00 cil -4.00 esf
-1.75 cil -4.00 esf
-1.50 cil -4.00 esf
-1.25 cil --4.00 esf
-1.00cil -4.00esf
-0.75 cil -4.00esf
-0.50 cil -4.00 esf
-0.25 cil -4.00 esf
0.00 -4.00 esf
-2.00cil -3.75 esf
-1.75 cil -3.75 esf
-1.50 cil -3.75 esf
-1.25 cil --3.75 esf
-1.00cil -3.75esf
-0.75 cil -3.75esf
-0.50 cil -3.75 esf
-0.25 cil -3.75 esf
0.00 -3.75 esf
-2.00 cil -3.50esf

.
.
.
0.00 cil 0.00 esf
-2.00 cil +0.25 esf
........

hasta 0.00 cil +4.00 esf

se que es un rollo pero creo que así podeis enter lo que quiero decir.


cada línea que os hepuesto ahi arriba es una diferente graduación que cada lente puede tener, de hecho tenemos en stock pues lentes de cada graduacion.

Igual en este frase lo resumo, imaginemos que tengo dos camisetas mismo modelo color etc, pero tengo una en talla xl y otra en talla s. Cada lente tiene su graduacion, hay lentes de todas las graduaciones (dentro de su rango claro), y tenemosctodas las graduaciones de ese rango que he intentado plasmar ahí arriba, no hay mas cosa.

Siento explicarlo asin a lo bruto , pero creo que se entenderá

[David_Carrera_G]

Estimado, estimado he tenido la oportunidad de ver como funciona un programa de generación de OT para lentes opticos y de contacto, por lo cual puedo imganinarme la funcionalidad, adjunto lo que enviaste en el TXT.

Código MySQL:

CREATE TABLE `lentes` (
  `id` int(2) NOT NULL AUTO_INCREMENT,
  `lente` varchar(100) NOT NULL,
  `desc` varchar(100) NOT NULL,
  `Abbe` int(2) NOT NULL,
  `densidad` varchar(50) NOT NULL,
  `geometrÃ*a` varchar(15) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `tipo` (`lente`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=12 ;
 

Yo generaría otras tablas, en las cuales capturare solo la graduación de la lentilla separando el cilindro de la esfera
seria algo así

Código MySQL:

CREATE TABLE graduacion_esfera(
ID_esfera int(5) NOT NULL AUTO_INCREMENT,
graduacion varchar(5) NOT NULL
PRIMARY KEY(ID_esfera));
 
CREATE TABLE graduacion_cilindro(
ID_cilindro int(5) NOT NULL AUTO_INCREMENT,
graduacion varchar(5) NOT NULL
PRIMARY KEY(ID_cilindro));
 

De esa forma podría capturar tanto la variación de la esfera como del cilindro, al elegir un lente.

[gralf]

supongo que de este modo no tengo que repetir tantas graduaciones, no?

por cierto que opcion eliges para mostrar el codigo mysql?

[David_Carrera_G]

Claro de este modo, especificas las graduaciones de las esferas como los cilindros, y luego solo los vas eligiendo mediante la clave foránea que se debe generar entre cilindros y esferas con los lentes.

Y el SQL lo pegas, luego lo seleccionas y en HIGHLIGHT seleccionas SQL o MYSQL

[gralf]

muy bien pues esto es lo que tengo de momento



Con los datos de las graduaciones introducidos

[David_Carrera_G]

Estimado, no se observa lo que adjuntas, favor revisar el post una vez lo hayas realizado, saludos.-

[gralf]

Pues yo veo la captura que he enviado......si te refieres a eso

[gralf]

Iniciado por gnzsoloyo

A mi entender el problema que tienes es que estás mirando los detalles de los productos en lugar de hacer una abstraccion de los mismos y tratar de deterimar las características de las entidades que los contienen.
Antes de proceder a diseñar tablas y relaciones debes definir los objetos que contiene ese sistema y a partir de ellos definir cuales son los atributos que poseerán las entidades en un modelado relacional que las pueden incluir.

Si sigues pensando en los valores de los datos, en lugar de los datos como atributo, se volverá confuso.

Lamentablemente no tenemos un subforo dedicado al analisis de sistemas, que es el punto debil de todo este caso que describes, sino movería el post para alla.

En lo que parece ser, hay que definir algunas cosas:

- Qué atributos son propios de los Lentes como abstracción, es decir ¿qué atributos son comunes a TODOS los lentes?

- Qué Tipos de Lentes existen y en qué se diferencian. Esto determinará una cosa: Si no existen atributos que los diferencien, y sólo se diferencian en el uso que se da al lente fisicamente hablando (el objeto tangible), entonces los tipos no son parte del modelo de datos, sino del proceso de la aplicacion.
Pero si los tipos muestran una o más diferencias de atribuitos que son propios de uno u otro tipo, entonces la Entidad Lente puede tener una relacion con otra de Tipos de Lente, o bien existe una jerarquia de herencia, lo que implica que Lentes compondrá más de una tabla.

- ¿Qué es una graduación y en qué atributos se descompone? Cuando haces la descripcion de los valores pareces describir ciertos rangos de magnitudes quese usan respecto de un lente. Lo que edbes definir es qué describe cada magnitud y cuantas se necesitan para describir una sola graduacion.

- Si una graduación aplica a un único tipo de lente, la propia tabla degraduaciones (de necesitar existir) podría relacionarse con el tipo de lente sea en forma directa como transitiva. Hay que definir mejor eso.
Pero si una misma graduacion (con todas sus magnitudes) sólo apolica a un único tipo de lente, entonces es probable que las graduaciones sean parte de los atributos propios de Lente. Sólo se justificaría que graduaciones sea una tabla aparte si se forman conjuntos repeteitivos de magnitudes entre dos lentes diferentes.

- Finalmente, el stock apunta a una relacion de todos los elementos en un único registro. Pero para definir esa relacion hay que primero definir lo previo.

Nota bene: No confundas los valores que una graduación tiene, con los atributos que componen la graduación. A nivel de diseño bases de datos, los valores no existen, sólo existen los dominios que implica el rango de representacion que un mismo atributo tendrá.
Los valores que un registro contenga son propios de la instancia (registro físico), y no parte del modelado.

¿Se entiende?

Trata de describir los elemntos que te digo de un modo más abstracto. de ese modo te acercarás mejor a la estructura correcta de la base que necesitas. No te pierdas en los detalles.

intento comprender todo lo que explicas en tu respuesta, aunque no es fácil, hablas de conceptos "abstractos" que me cuesta entender, aún así lo intento, de hecho he echado mano de algunos apuntes y buceado por la red.

en conclusion en el punto que me encuentro, podemos decir que lentes cilindro y esfera son entidades?

cada lente junto con la union de una esfera y un cilindro forman un unico objeto, ¿no?

como debo relacionar estas tablas?

[solmedina87]

Por lo que he leido tenes un lente (con su abbe, dens, etc) y cada lente puede tener distintas esferas y cilindros entonces la relación que deberías hacer para relacionar elementos de cada una de esas 3 entidades es armar otra tabla donde guardes:
id de Lentes
id de Cilindros
id de Esferas

[gralf]

Iniciado por solmedina87

Por lo que he leido tenes un lente (con su abbe, dens, etc) y cada lente puede tener distintas esferas y cilindros entonces la relación que deberías hacer para relacionar elementos de cada una de esas 3 entidades es armar otra tabla donde guardes:
id de Lentes
id de Cilindros
id de Esferas

gracias por la respuesta.

y digo yo, y como guardo esos id?

quiero decir, creo la tabla

Código MySQL:

CREATE TABLE  `lentesrel` (
 `id_lentesrel` INT( 20 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
 `ID_cil` INT( 20 ) NOT NULL ,
 `ID_esf` INT( 20 ) NOT NULL ,
 `ID_lente` INT( 20 ) NOT NULL
) ENGINE = INNODB;
 

en ella se guardarán las combinaciones posibles? o cómo funciona esta tabla?

quiero decir, cómo se guardan las posibles combinaciones aquí?

[gralf]

estoy pensando que igual me estoy adelantando y tal y como decís por ahí arriba necesitamos abstraernos para diseñar bien todo esto. Estoy viendo apuntes y tal y se me ha ocurrido que quizás sea mejor empezar por diseñar el modelo para ir viendo como desarollar luego las tablas y relaciones.

he empezado con esto

tengo estas entidades

-lentes
-graduacion esferica
-graduacion cilíndrica

y he hecho un diagrama en el que he intentado plasmar cardinalidades, no se si están bien, creo que si, pero pasaré a explicarlo, ospongo una captura.



lo que intento explicar con este diagrama es que

eso, tres entidades

una graduacion esferica puede tener 0 o varios lentes y un lente tiene una o varias graduacioes esfericas

en el caso de la graduacion cilindrica pues lo mismo

y entre las entidades graduacion esferica y g. cilindrica pues, una g. cilindrica tiene entre 0 y varias graduaciones efericas y viceversa.

creo qu elo tengo bien representado, ya me direis.

otra cosa será representar lo que necesito para luego inventariar, me refiero a las entidades que harán falta, pero me parece un buen comienzo.

[gralf]

siento la autorespuesta, pero despues de estar pensando en esto un rato me doy cuenta que no se si hay un error, bueno, creo que si lo hay

entre esfera y cilindro, la cardinalidad pienso que está mal, por pensar en los datos, y ya me habeis dicho que no hay que pensar en ellos en este paso.

el caso es que para tener una graduacion completa viene dada por un cilindro y una esfera; sería entonces una relacion (1,1) verdad?

[gralf]

pues despues de darle vueltas de nuevo, creo que no, que estaba bien, y sale una relacion muchos a muchos que entiendo es de donde luego se crea la tabla que dice solmedina87.

es asÍ?



de serlo, que os parece este modelo





de todos modos aquí hay algun error, porque esto es lo que dice phpmyadmin de las tablas Rx e Item






parece qeu no se lee el texto, pues pone esto

PRIMARY and INDEX keys should not both be set for column `Rx_cilindro_ID_cil`y en space usage/overhead sale en rojo

[gralf]

siento el up, pero en serio, no podeis intentar aconsejarme algo sobre este modelo? tengo dudas y muchas, pero el tema se ha estancado.

[solmedina87]

No estoy segura del error que te da phpmyadmin pero hablando sobre el modelo que pusiste, no entiendo para que la tabla RX... Con las demás entiendo que sería suficiente es decir:
Tus 3 entidades para mi están bien (lentes, esfera y cilindro).

Y se deberían relacionar en la tabla ITEM... Que también creo que la tenés bien, porque tenes los id de las otras tres entidades... Esos 3 id, en la tabla ITEM tienen que ser FOREING KEY, es decir que deben hacer referencia a sus tablas de origen (Lente, esfera y cilindro).

De nuevo, no entiendo el error que te da pero intenta sacar esa tabla RX o contame para que está? porque hasta donde entendí un lente tiene 1 esfera y 1 cilindro (mas alla de que una esfera pueda relacionarse con mas de un cilindro y vicebersa)

[gralf]

Iniciado por solmedina87

No estoy segura del error que te da phpmyadmin pero hablando sobre el modelo que pusiste, no entiendo para que la tabla RX... Con las demás entiendo que sería suficiente es decir:
Tus 3 entidades para mi están bien (lentes, esfera y cilindro).

Y se deberían relacionar en la tabla ITEM... Que también creo que la tenés bien, porque tenes los id de las otras tres entidades... Esos 3 id, en la tabla ITEM tienen que ser FOREING KEY, es decir que deben hacer referencia a sus tablas de origen (Lente, esfera y cilindro).

De nuevo, no entiendo el error que te da pero intenta sacar esa tabla RX o contame para que está? porque hasta donde entendí un lente tiene 1 esfera y 1 cilindro (mas alla de que una esfera pueda relacionarse con mas de un cilindro y vicebersa)

antes de nada, gracias por tu respuesta, pensaba que este tema quedaba estancado.

pues ahora que lo dices teniendo el cil y la esf puedo construir la Rx (graduacion) sinn necesidad de una tercera tabla.

Aún así , te cuento de donde me ha salido la tabla. tengo este diagrama



al estar relacionados n,m esfera y cilindro, no debe crearse una tabla entre las dos? pensaba que era así, pero igual el error es haber relacionado esas dos tablas.

me has abierto los ojos y claro, sería una redundancio, porque todas las combinacines de graduaciones pueden conseguirse con la esf y el cilindro ¿no?

quedaria el modelo de este modo entonces?



y con este esquema...

Código MySQL:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
 
CREATE SCHEMA IF NOT EXISTS `stocklentes` DEFAULT CHARACTER SET utf8 ;
USE `stocklentes` ;
 
-- -----------------------------------------------------
-- Table `stocklentes`.`Index`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `stocklentes`.`Index` (
  `id_index` INT(2) NOT NULL AUTO_INCREMENT ,
  `nombre` VARCHAR(100) NOT NULL ,
  `Abbe` INT(2) NOT NULL ,
  `dens` VARCHAR(50) NOT NULL ,
  `geom` VARCHAR(15) NOT NULL ,
  `Indexcol` VARCHAR(45) NULL ,
  PRIMARY KEY (`id_index`) ,
  UNIQUE INDEX `nombre_UNIQUE` (`nombre` ASC) )
ENGINE = InnoDB
AUTO_INCREMENT = 12
DEFAULT CHARACTER SET = utf8;
 
 
-- -----------------------------------------------------
-- Table `stocklentes`.`esf`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `stocklentes`.`esf` (
  `id_esf` INT(5) NULL AUTO_INCREMENT ,
  `esf` DECIMAL(5,2) NULL ,
  PRIMARY KEY (`id_esf`) ,
  UNIQUE INDEX `esf_UNIQUE` (`esf` ASC) )
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `stocklentes`.`cil`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `stocklentes`.`cil` (
  `id_cil` INT(5) NULL AUTO_INCREMENT ,
  `cil` DECIMAL(5,2) NULL ,
  PRIMARY KEY (`id_cil`) ,
  UNIQUE INDEX `cil_UNIQUE` (`cil` ASC) )
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `stocklentes`.`Iem`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `stocklentes`.`Iem` (
  `id_item` INT(5) NOT NULL AUTO_INCREMENT ,
  `id_item_index` INT(5) NOT NULL ,
  `id_cil` INT(5) NOT NULL ,
  `id_esf` INT(5) NOT NULL ,
  PRIMARY KEY (`id_item`) ,
  INDEX `fk_index_rx_idx` (`id_item_index` ASC) ,
  INDEX `fk_Iem_cil1_idx` (`id_cil` ASC) ,
  INDEX `fk_Iem_esf1_idx` (`id_esf` ASC) ,
  CONSTRAINT `fk_index_rx`
    FOREIGN KEY (`id_item_index` )
    REFERENCES `stocklentes`.`Index` (`id_index` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Iem_cil1`
    FOREIGN KEY (`id_cil` )
    REFERENCES `stocklentes`.`cil` (`id_cil` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Iem_esf1`
    FOREIGN KEY (`id_esf` )
    REFERENCES `stocklentes`.`esf` (`id_esf` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
 
 
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
 

[solmedina87]

Para mi te quedó bien el esquema y el SQL :)

[gralf]

muy bien.
ahora lo siguiente sería el tema stock, lo que quiero es llevar el conteo de lo que tengo.
y dentro del stock querría hacer entradas (cuando compro mercancia) , hacer salidas (por dos motivos, por venta o por taller) y hacer regularizaciones.

supongo que una tabla entradas será algo así

id_entrada, id_item (para relacionarlo con item), timestamp (para saber fechas), y numero ¿os parece correcto?

de ser así?

necesito una tabla para cada una de las tres cosas, y como puedo resolver el tema de que haya dos tipos de salidas?



había pensado en estas tablas como entrada y salida

Código MySQL:

-- -----------------------------------------------------
 
-- Table `stocklentes`.`salida`
 
-- -----------------------------------------------------
 
CREATE  TABLE IF NOT EXISTS `stocklentes`.`salida` (
 
  `id_salida` INT(5) NOT NULL AUTO_INCREMENT ,
 
  `salida` INT(5) NULL ,
 
  `fecha_salida` TIME NULL ,
 
  `tipo_salida` ENUM('venta', 'taller') NULL ,
 
  `id_item` INT(5) NULL ,
 
  PRIMARY KEY (`id_salida`) ,
 
  INDEX `fk_salida_item_idx` (`id_item` ASC) ,
 
  CONSTRAINT `fk_salida_item`
 
    FOREIGN KEY (`id_item` )
 
    REFERENCES `stocklentes`.`Item` (`id_item` )
 
    ON DELETE NO ACTION
 
    ON UPDATE NO ACTION)
 
ENGINE = InnoDB;
 
 
 
 
 
-- -----------------------------------------------------
 
-- Table `stocklentes`.`entrada`
 
-- -----------------------------------------------------
 
CREATE  TABLE IF NOT EXISTS `stocklentes`.`entrada` (
 
  `id__entrada` INT(10) NOT NULL AUTO_INCREMENT ,
 
  `entrada` INT(5) NULL ,
 
  `fecha_entrada` TIMESTAMP NULL ,
 
  `id_item` INT(5) NULL ,
 
  PRIMARY KEY (`id__entrada`) ,
 
  INDEX `fk_entrada_item_idx` (`id_item` ASC) ,
 
  CONSTRAINT `fk_entrada_item`
 
    FOREIGN KEY (`id_item` )
 
    REFERENCES `stocklentes`.`Item` (`id_item` )
 
    ON DELETE NO ACTION
 
    ON UPDATE NO ACTION)
 
ENGINE = InnoDB;
 

no se si el campo enum solucionará lo de los dos tipos de salidas. Y el tema FK ¿estaría bien así?

y no se si necesitaría esa tercera table para regularizaciones, o bien puedo usar entradas y salidas y usar una opcion mas en el campo enum?.

bueno, ya me contareis.

gracias de antemano

[gralf]

bueno, me he echado palante y he llegado a esto

Código MySQL:

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
 
-- 
-- Database: `stocklentesbrujuleando`
-- 
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `cilindro`
-- 
 
CREATE TABLE `cilindro` (
  `ID_cil` int(2) NOT NULL AUTO_INCREMENT,
  `cilindro` decimal(5,2) NOT NULL,
  PRIMARY KEY (`ID_cil`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=18 ;
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `entrada`
-- 
 
CREATE TABLE `entrada` (
  `id_entrada` int(5) NOT NULL AUTO_INCREMENT,
  `entrada` int(5) DEFAULT NULL,
  `fecha_entrada` timestamp NULL DEFAULT NULL,
  `tipo_entrada` enum('compra','regul') DEFAULT NULL,
  `id_item` int(5) NOT NULL,
  PRIMARY KEY (`id_entrada`),
  KEY `fk_entrada_item1_idx` (`id_item`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `esfera`
-- 
 
CREATE TABLE `esfera` (
  `ID_esf` int(5) NOT NULL AUTO_INCREMENT,
  `esfera` decimal(5,2) NOT NULL,
  PRIMARY KEY (`ID_esf`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=75 ;
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `item`
-- 
 
CREATE TABLE `item` (
  `item_ID` int(5) NOT NULL AUTO_INCREMENT,
  `ID_Item_Rx_cil` int(2) NOT NULL,
  `ID_Item_RX_esf` int(5) NOT NULL,
  `ID_Item_RX_lente` int(2) NOT NULL,
  PRIMARY KEY (`item_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `lentes`
-- 
 
CREATE TABLE `lentes` (
  `ID_lente` int(2) NOT NULL AUTO_INCREMENT,
  `lente` varchar(25) NOT NULL,
  `desc` varchar(45) NOT NULL,
  `Abbe` int(2) NOT NULL,
  `densidad` varchar(15) NOT NULL,
  `geometría` varchar(15) NOT NULL,
  `id_item` int(5) NOT NULL,
  PRIMARY KEY (`ID_lente`),
  UNIQUE KEY `tipo` (`lente`),
  KEY `fk_lentes_item1_idx` (`id_item`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=12 ;
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `rx`
-- 
 
CREATE TABLE `rx` (
  `Id_Rx` int(2) NOT NULL DEFAULT '0',
  `ID_Rx_cil` int(2) NOT NULL,
  `ID_Rx_esf` int(5) NOT NULL,
  `id_item` int(5) NOT NULL,
  `rxcol` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`Id_Rx`),
  KEY `fk_cilindro_has_esfera_idx_idx` (`ID_Rx_cil`),
  KEY `fk_esfera_has_cilindro_idx_idx` (`ID_Rx_esf`),
  KEY `fk_rx_item1_idx` (`id_item`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
-- --------------------------------------------------------
 
-- 
-- Table structure for table `salida`
-- 
 
CREATE TABLE `salida` (
  `id_salida` int(5) NOT NULL AUTO_INCREMENT,
  `salida` int(5) DEFAULT NULL,
  `fecha_salida` timestamp NULL DEFAULT NULL,
  `tipo_salida` enum('venta','taller','regul') DEFAULT NULL,
  `id_item` int(5) NOT NULL,
  PRIMARY KEY (`id_salida`),
  KEY `fk_salida_item1_idx` (`id_item`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
 
-- 
-- Constraints for dumped tables
-- 
 
-- 
-- Constraints for table `entrada`
-- 
ALTER TABLE `entrada`
  ADD CONSTRAINT `fk_entrada_item1` FOREIGN KEY (`id_item`) REFERENCES `item` (`item_ID`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 
-- 
-- Constraints for table `lentes`
-- 
ALTER TABLE `lentes`
  ADD CONSTRAINT `fk_lentes_item1` FOREIGN KEY (`id_item`) REFERENCES `item` (`item_ID`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 
-- 
-- Constraints for table `rx`
-- 
ALTER TABLE `rx`
  ADD CONSTRAINT `fk_cilindro_has_esfera_idx` FOREIGN KEY (`ID_Rx_cil`) REFERENCES `cilindro` (`ID_cil`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  ADD CONSTRAINT `fk_esfera_has_cilindro_idx` FOREIGN KEY (`ID_Rx_esf`) REFERENCES `esfera` (`ID_esf`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  ADD CONSTRAINT `fk_rx_item1` FOREIGN KEY (`id_item`) REFERENCES `item` (`item_ID`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 
-- 
-- Constraints for table `salida`
-- 
ALTER TABLE `salida`
  ADD CONSTRAINT `fk_salida_item1` FOREIGN KEY (`id_item`) REFERENCES `item` (`item_ID`) ON DELETE NO ACTION ON UPDATE NO ACTION;
 

os pongo el err



creo que está bien para ese control de stock.

mis dudas están en las FK, os parece que están puestas correctamente?

gracias de antemano