Recomendaciones sobre esta tabla si dividirla en 2 o no.

[matiD]

Como están?

Bueno necesito una recomendación, hace unos meses ya bastante tiempo atrás presenté un trabajo que estaba realizando, recien ahora puedo seguir con el mismo y estoy paso a paso.

Acabo de llegar al momento de crear la tabla de ordenes de trabajo. La cual muy amablemente un usuario de este foro me recomendó que debería separarla en 2 tablas porque son entidades distintas las máquinas que se repararán y las ordenes de trabajo.

Bien para comenzar explico de que consta la tabla y un poco el sistema.

Necesito principalmente poder cargar ordenes de trabajo de servicio técnico, no las voy a cargar solo yo, y le consulté a los clientes si preferían cargar a través de campos select o cargar ellos mismos la marca el modelo y demás. el 92% prefirío el ejemplo con carga manual de modelo y marca de los productos. Ya que con el Autocomplete mientras no borren el historial y demás si ya escribieron algo la próxima vez les aparece la opción y a veces entienden de manera diferente marca y modelo, Por ejemplo la mayoría de los clientes en una XBOX360 para ellos la marca era XBOX 360 y el modelo Fat o Slim, cuando la marca debería ser Microsoft. Pero bueno por tal motivo ellos completaran manualmente esos atributos.

ya teniendo esta idea principal es donde me surge la duda, para mí en mi cabeza, la orden de trabajo debe incluir todos los valores referentes a dicho trabajo a realizar y por esto ser una sola tabla, pero también me suena muy logico la explicación de un usuario mucho más avanzado que me indica que mejor sería separarlos.

Yo en mi cabeza la tabla de ordenes de trabajo la pienso de esta manera.

Código MySQL:

CREATE TABLE IF NOT EXISTS ordenes(
orden int unsigned NOT NULL auto_increment,
id_cliente int unsigned NOT NULL,
marca varchar(20),
modelo varchar(20),
numserie varchar(40) NOT NULL,
procedencia tinyint unsigned NOT NULL,
categoria tinyint unsigned NOT NULL, 
servicio VARCHAR (40) unsigned NOT NULL,
precio decimal(6,2),
senia decimal(6,2),
movimientos int NOT NULL,
ubicacion tinyint DEFAULT '1',
detalles varchar(255),
garantia int,
PRIMARY KEY (orden),
INDEX (numserie),
FOREIGN KEY (id_cliente) REFERENCES clientes(id_clientes),
FOREIGN KEY (procedencia) REFERENCES locales(id_locales),
FOREIGN KEY (categoria) REFERENCES categ_servicios(id_categservicios),
);
 

por favor si pudieran darme una mano y/o recomendaciones para que sería lo mejor les agradecería!!!

Desde ya muchas gracias por todo!!!

[zalito12]

Por lo que cuentas probablemente esta estructura no te genere problemas, al menos de momento.
Pero creo que el usuario que te recomendó separarlo sabe de lo que habla. Si a mi me plantean el problema desde cero probablemente lo hiciese con 2 entidades distintas.
Si te fijas en orden guardas el número de serie de los productos. Un número de serie es algo que de por si suena a identificador. A parte guardas muchos otros atributos que no están relacionados directamente con la orden.
Probablemente deberías cambiarlo, a no ser que te genere mucho trastorno a estas alturas o incluso a pesar de ello. Podrías incluir un atributo Fabricante dónde si indicar Microsfot, Sony, etc. El número de serie junto con el fabricante deberían ser un buen identificador ya que no deberían repetirse aunque no estoy 100% seguro ya que no sé como funcionan los fabricantes.

Con esas dos entidades dividas tendrías que cambiar algunas cosas en las relaciones. El cliente estaría relacionado con su propio producto y no con la orden de trabajo, lo cúal tiene mucho sentido. Las órdenes se relacionarían con los productos y creo que no se genera ninguna trampa de conexión de esta manera aunque habría que estudiar el resto de la DB.

Suerte.

[matiD]

Me parece interesante, y puede servir para dentro de un tiempo para varios motivos como por ejemplo contactar a clientes por X actualización que haya para ciertos productos, y demás. Muchas gracias por la aclaración, no es problema ya que antes estaba desarrollando todo por procedimientos, ya ahora empecé toda la programación de cero orientada a objetos. así que de paso también hice algunos retoques en la BD que también inicie de cero.

Saludos!!!