Hola Sajer, pues depende de cómo quieras controlar el precio, yo lo pondría en la tabla de cat_material, ahora que si cada que recibes material te cambian el precio, lo pondría en la de tab_recepciondeMaterial, ligada a la de cat_material, así al hacer una consulta puedes saber el precio del material en el día que te lo entregaron, pero si no cambia tanto, yo lo pongo en la primera

Espero que te sirva
Saludos

Gracias

Gracias vhluja por contestar creo que son muy buenas tus observaciones al respecto y la verdad que no tengo mucha experiencia en diseño de base de datos por eso acudo al corral Bakuno

Gracias y saludos

OK, espero que te ayude

Saludos

yo sic reo q tenga q ir en la de material xq asi puedes controlar el precio cuando se vaya a cambiar

Todo depende del metodo de costeo que utilizes en el sistema.
Si capturas el precio cada que te llega en compra, entonces te servira el metodo de costeo de precio promedio.
Salu2

Es como te dijo vhluja.

Si pones el precio en la tabla de recepción, solo vas a tener una gran redundancia de precios, pues será el mismo precio hasta que lo cambien.

Si lo pones en la tabla de cat_material, solo lo pones una vez, y al momento de cambiar precios, solo los cambias una vez por material. Esta sin duda es la mejor manera.

Ahora, bien, existe un problema. La 1ra opción, la de guardar el precio cada vez que ingresa material, tiene la ventaja de que al momento de hacer consultas historias, estan bien definidas las fechas en los que se cambio el precio del material, y además cada material se guardo con el precio de ese entonces.

Por el contrario, con la 2da opción, a la hora de un cambio vas guardando el nuevo precio ... pero, ¿y el anterior? ¿Qué pasa si luego te piden una consulta con el total de material ingresado, agrupados por cada uno de los diferentes precios que ha manejado la compañía? Ahí hay un problema.

Quizá para una tarea de diseño, lo podes dejar como dijo vhluja, pero si es para una aplicación real es necesario que además de eso, agregues una tabla de registro histórico para los cambios de precios (con campos fecha_cambio y precio_nuevo). De esta manera te evitas la redundancia de datos (precio en este caso), y además tenes información de cuando se hizo un cambio en el precio. En este último caso la tabla podría ir "suelta" no necesariamente relacionada, ya que es un histórico.

Saludos