consulta con modelo relacional

[uamistad]

Hola Thor, thanks.

Mira, el diseño está bien y el otro también estaba bien y anotar los datos en un cuaderno también está bien si nada más se tratara de almacenar información. Pero el objetivo aquí es que usar la DB debería ser un medio para extraer la información rápido cuando se requiera.

Lo que no sé es qué tipo de información solicitaría la empresa, pues el diseño se basa más bien en qué es lo que se pretende extraer de ella.

Hazte preguntas acerca de qué es lo que le quieres extraer a la base de datos, pues tú más que nadie conoce lo que esta empresa necesitará.

No sería necesario agregar detalles del pedido por ejemplo ya que mencionas que eso le corresponde a la gente de ventas, pero ya que tú estás encargado del control de inventario, tienes uno de los módulos más importantes del sistema en tus manos (y la responsabilidad).

Parece que más o menos he entendido el funcionamiento de la empresa, pero deberías hacerte preguntas sobre lo que se necesitará.

Te comenté que sería bueno que independizaras al producto de su precio porque quizá alguien se podría preguntar, ¿cuánto se gastó Juan Chuchito en sus compras de Diciembre y qué fue lo que compró?

El si esta pregunta es algo que tu sistema debe solucionar, pues independizando una tabla de precios no lo vas a poder saber, más bien tendrías que anotar en qué consiste el pedido de Juan Chuchito y con los precios de aquél tiempo. Por lo que Ese campo de precio, no importa que lo hayas independizado o no, no sirve para responder esa pregunta.

En general sería dificil adivinar las preguntas que esa empresa que tienes en mente se haría. En el post anterior se me ocurrieron algunas que tu sistema no podía resolver y si éstas eran importantes, pues tendrías que re-estructurar el diseño para que pudiera hacerlo.

Aún el diseño más completo es insuficiente para algunas preguntas muy estrictas, como por decir, ¿quién fue el usuario que borró los productos que se ingresaron ayer? Es una pregunta que obliga a un diseño más sólido y que quizá la empresa que requiere este diseño no se preguntaría porque confía en todos sus empleados.

A eso es a lo que me refiero con las 'preguntas correctas', todo diseño de bases de datos debería incluir una introducción de lo que el sistema pretende hacer, no sólo de la descripción de la empresa.

Cuando hago mis diseños comienzo por algún diseño 'esqueleto' como el tuyo y luego empiezo a preguntarme:

"¿me interesaría registrar qué forma de pago usó el cliente?" "Me interesaría llevar un control de los pagos que hace un cliente, de un producto que compró en abonos y cada cuándo se están registrando esos pagos y recibir alertas de cuando un cliente no haya cumplido con su pago?"

Etc, etc.

Un diseño no es mejor por ser más grande que otro.

Si tú pones una tabla de teléfonos porque tu cliente pudiera ser que actualice sus teléfonos constantemente y en lugar de simplemente actualizar el nuevo teléfono de tu cliente quieres llevar un control de cada cuándo están cambiando de número telefónico y tener acceso a esas consultas, ¿te parecería demasiado?

Posiblemente, pero si en lugar de teléfonos fueran números de tarjeta, ahí quizá no sería demasiado, pues un mismo cliente podría usar tarjetas diferente y no por que cambie de tarjeta vas a meter el registro de tu cliente COMO SI FUERAN DOS CLIENTES DIFERENTES si es que te interesa poder contestar la pregunta: "¿Cuáles son las compras que el cliente con ID 3423 ha hecho en nuestra tienda?"

CONCLUSIÓN

Imagínate preguntas y mira si tu diseño las puede contestar. Tu diseño como te digo está bien así como está si nadie se va a preguntar nada. También te serviría un cuadernito y un lápiz.

Pero ya que vas a necesitar EXTRAER de ese diseño cierta información, debes hacerte preguntas y diseñar la DB de forma que éste sea una respuesta funcional de las preguntas que te hiciste.

"No está bien ni está mal, todo depende de las preguntas que tu diseño deba contestar."

Jaja, el párrafo anterior lo enmarqué con comillas porque salió con rima y todo.

Suerte =)