Duda con diseño de Base de Datos

[GUN10]

Hola buenas noches!

Les comento que estoy realizando un pequeño sistema para un servicio tecnico y me encuentro con la siguiente duda sobre el diseño de la base de datos.

Estoy por empezar a crear el formulario donde tendria lo que es la "orden de reparacion" que seria lo que creo cuando el cliente viene con su equipo a reparar.

En mi base de datos tengo las siguientes tablas vinculadas (clientes, ordenreparacion y detalleordenreparacion)

La idea es que cuando llegue un cliente con su equipo a reparar, cree la orden de reparacion, donde guardare datos como "codigo de orden, fecha de ingreso, categoria del equipo, marca, modelo, usuario que recibe el equipo, detalle de como ingresa, detalle de la falla".

A su vez debo crear un "detalle de esa orden de reparacion", donde tendre informacion sobre el "codigo de detalle, estado del equipo, detalle tecnico , fecha de finalizacion de la reparacion, tecnico que realizo la reparacion"

Lo que me di cuenta a la hora de querer empezar a diseñar ya el formulario es, si que pasaria en el caso de que un cliente lleve mas de un equipo a reparar , por ejemplo un monitor, una impresora y una notebook.
No tendria lugar para guardar ya que solo tendria en la tabla "orden de reparacion" un campo para "categoria, marca y modelo".

Lo que planteo es, me conviene generar otra orden de reparacion y detalle de reparacion para cada equipo o es conveniente crear una tabla "equipos" y asociarla a la tabla clientes ??

Desde ya muchas gracias por la ayuda como siempre. Saludos!!

[[AgustinOrtu]]

Es que la respuesta a esa pregunta no te la podemos dar, porque eso lo decide quien te compra el programa

[GUN10]

Mi pregunta era si que harían ustedes en mi situación.

Ingresarian una orden de reparación para casa equipo que el cliente lleve o crearían una tabla donde guarde los diferentes equipos que el cliente lleva....

La segunda opción no se si es la correcta ya que tendría muchos registros iguales en el caso de que el usuario lleve el mismo equipo varias veces... "categoría, marca, modelo, etc"

[[ElKurgan]]

Es que en teoría debería ser así. La tabla de Ordenes debe tener una sóla orden (maestro) y una de equipos asociados a la orden (clave foránea), que sería otra de detalles, independiente de la de detalles de reparación. Esto a su vez obligaría a tener una tabla que relacionara "muchos a muchos" los detalles de ordenadores de la orden y los detalles de reparación.

O al menos es lo que he entendido de tu consulta

Saludos

[jafera]

Buenos dias.

Y si mañana el cliente vuelve con otra reparacion?
Se debe generar una nueva orden, no?

Yo lo que haria es antes de diseñar el formulario de entrada crear un buen esquema de la base de datos, es mejor perder un tiempo en este diseño que luego ir ampliando campos, modificando sql, etc.

En tu caso debes decidir quien manda, si la orden de reparacion y le asignas el cliente o el cliente al que le asignas la orden de reparacion.

Tabla clientes
ID, nombre, telefono etc.

Tabla orden reparacon
ID, ID_Cliente (para que lo ligue), tipo de reparacion y lo que quieras

Tabla detalle reparacion
ID_Reparacion, detalles, etc..

Saludos

[[AzidRain]]

Esto pasa cuando ya estamos diseñando interfaz de usuario y no hicimos un correcto análisis, arquitectura y modelado de los procesos del cliente. Partiendo desde el proceso y olvidándonos por un momento de que si la tabla y si no se que...veamos: Un cliente puede llevar varios equipos a reparar ok...Al ser diferentes equipos es obvio que no quedarán reparados todos al mismo tiempo independientemente de si el cliente quiere o no recogerlos todos juntos. Por lo tanto, lo correcto es que cada orden de reparación se refiera a un único equipo ya que de esta forma podremos dar seguimiento a cada reparación e inclusive el cliente podría hacer referencia a cada orden cuando pregunte por lo que se le podrá informar conforme vayan quedando terminadas las órdenes.

Si observas el modelado que sigue a la descripción del proceso cambia en función de estos requerimientos. De ahí que creo que deberías de modelar perfectamente los procesos con tu cliente para que ya sobre esa base bien firma puedas hacer lo demás y no te pase lo que ahorita, que ya tienes algo modelado y vas a tener que modificarlo.

[TiammatMX]

Empezado por GUN10

...En mi base de datos tengo las siguientes tablas vinculadas (clientes, ordenreparacion y detalleordenreparacion)...

...y así, mis queridos alumnos es como NO DEBE realizarse un análisis de diseño de una aplicación...

El mejor consejo que alguna vez me dieron en la Profesional (hace casi 30 años) es: Entérate PERFECTAMENTE de qué espera el usuario obtener AL FINAL de tu proceso y diseña hacia atrás cada uno de los programas, tablas, conectores, catálogos, configuraciones y todo lo que involucre la interacción con el ser humano.

Un pequeño consejo (que también es muy útil): Trabaja tu programa pensando en que TODOS LOS USUARIOS SON IDIOTAS y sólo así triunfarás en tu proyecto.

[GUN10]

Muchas gracias por las respuestas que me dieron!

Quería aclarar que las tablas que mencione no son las únicas que tengo en la base de datos. Sino que las mencione porque eran sobre las que tenia dudas.
Al final realizando mas diseños en papel, pruebas y demás. Resolví como mencionaron en una de las respuestas que para cada equipo que lleven un cliente a reparar, generar una "orden de reparacion y un detalle de reparacion" para poder tener el seguimiento del mismo.

Es un sistema que estoy realizando para mi por eso no tengo la posibilidad de preguntar a mi cliente que es lo que necesita, pero yo lo veo como cliente y como lo que me gustaria ver en el sistema cuando este funcionando.

Agradezco nuevamente los concejos y respuestas que me dieron. Saludos!!

[[AgustinOrtu]]

GUN10, me alegro que hayas encontrado solucion; evidentemente a mi tambien me parece la forma mas acertada

Aun asi, hay que tomar muy en cuenta lo que comentaron tanto AzidRain como TiammatMX

Solo hay un punto que me gustaria señalar que no comparto en demasía

Un pequeño consejo (que también es muy útil): Trabaja tu programa pensando en que TODOS LOS USUARIOS SON IDIOTAS y sólo así triunfarás en tu proyecto.

El buen Linus Torvalds dijo alguna vez algo muy similar a esto:

"Si crees que tus usuarios son idiotas, solo idiotas usaran tus programas"

Solo para tener en cuenta

Un saludo

[Casimiro Notevi]

Empezado por AgustinOrtu

Solo hay un punto que me gustaria señalar que no comparto en demasía
El buen Linus Torvalds dijo alguna vez algo muy similar a esto:
"Si crees que tus usuarios son idiotas, solo idiotas usaran tus programas"
Solo para tener en cuenta
Un saludo

Aunque hay que tener en cuenta que Linus Torvalds no ha hecho nunca software de gestión para empresas. Solamente ha hecho el sistema operativo Linux.

[TiammatMX]

Empezado por AgustinOrtu

..."Si crees que tus usuarios son idiotas, solo idiotas usaran tus programas"...

Trabajo con y para contadores..., enough said...

[mamcx]

Empezado por TiammatMX

Trabajo con y para contadores..., enough said...

Por ende, no deben ser idiotas:

http://es.thefreedictionary.com/idiota

Se aplica a la persona que está escasa o carece de inteligencia, que es torpe de entendimiento. estúpido, imbécil, tonto.

Imaginate como lo ve a uno un medico, ingeniero civil o algo similar cuando uno hace sus "apreciaciones" y demas.

Aunque uno entiende la idea de lo que dices, no es la palabra mas correcta.

Puede ser: "Ingenuo, inexperto, incompetente/ignorante (en su forma no insultante, pero toca usar un sinonimo porque siempre suena a insulto )" o similar. Ahora, ciertamente hay individuos con problemas mas serios "Arrogantes, perezoso, orgullosos, groseros" etc, que coincidencialmente son problemas morales y/o de comportamiento.

Incluso pienso que lo que dice Linus se puede interpretar mal (y siendo que Linus tiene fama de se tratar mal a otros y menospreciar cuando pierde los estribos no se que realmente quiso decir); yo lo entiendo en que si se hace una solución asumiendo que la gente es idiota, el programa sera idiota y forzara a gente capaz a portarse como idiota, porque asi es el programa.

----
En cambio, con lo que se expresa aqui, el problema ppal es falta de comunicacion, experiencia, ingenuidad, incompresion, detalles...