Base de datos Presupuestos

[hernino88]

Tengo que crear una base de datos de presupuestos, pero tengo el siguiente problema, cada presupuesto puede tener varios items, entonces dentro de la BBDD tengo la tabla:

CLIENTES
cli_id
cli_nom
cli_loc
cli_prov
cli_cp

PRESUPUESTO
pre_id
pre_num
pre_fec

Y mi duda es esta, tendría que crear otra tabla donde guarde los items adjuntados al presupuesto no?

NUMERO DE PRESUPUESTO (sería el nombre de la tabla, para identificarlo)
pre_num
pre_cod_item
pre_cant_item
pre_desc_item
pre_precio_item
pre_precio_total

Sería asi no?, entonces por cada presupuesto que guardo, tomo los datos de la tabla cliente, y en la tabla presupuesto, guardo el id del cliente, el numero de presupuesto y la fecha del mismo, y en la tabla XXX(número del presupuesto creado) guardo como ID el número del presupuesto, los codigos de los items, las cantidades, etc etc... mi gran pregunta...

Por cada presupuesto que cree tengo que crear una tabla nueva con todos los registros con el detalle del presu, o hay alguna otra forma de guardar muchos datos en un solo registro...???

Esto es más problema de diseño que de código, si me dan una mano se lo agradesco...

Saludos

[jchuk]

Hola, no se si ten entendí bien.

Porqué haces una tabla aparte para los número de presupuesto? No puede ir en la misma que presupuesto?

[gnzsoloyo]

No, jChuk, Está siguiendo las reglas de normalización (al menos la 3FN), por lo que la primera tabla tiene datos que no se deben repetir inútilmente, y la segunda es el detalle del presupuesto.
Y si, si sigues las reglas de normalización, el detalle va en otra tabla.

[jchuk]

Hola,

Por eso lo digo, porque se me escapa algo.
Si cada presupuesto tiene un número de presupuesto propio, me pregunto porqué cada presupuesto no tiene un precio propio (lo que formaría parte del detalle), ya que si lo tuviera, es un dato que puede (y creo que debe) ir en la segunda tabla y no en la tercera.
Es que no entiendo que datos van en la última tabla, por eso no entiendo si sobra o no.

Un saludo y gracias.

[gnzsoloyo]

No suele ir, porque el precio es un valor calculable, y otra de las reglas es que nunca almacenes un valor que se obtenga haciendo operaciones aritméticas con valores que ya tienes.
Es un desperdicio de recursos.
Piensa que sino, con cada operación pierdes 8 bytes de almacenamiento (que no se necesitan usar en realidad) cuando es un FLOAT, lo que después de cierta cantidad de operaciones se transforma en Kb, luego en Mb y finalmente en Gb inútiles.
Como en la última se indican los descuentos, el moto total surge de un cálculo SUM(campoA * CampoB)... Debería ir en la primera tabla, si y sólo si a la suma total se le aplica un descuento...

[jchuk]

Hola

Ya, ya, si tienes razón, he usado el precio como ejemplo, lo que quiero decir es que los campos que indica como pertenecientes a la tercera tabla me parecen campos únicos para cada presupuesto, por lo que no entiendo la razón de incluirlos aparte en una tercera tabla.

Lo que se está liando esto. En cualquier caso tienes razón en todo lo que me has comentado y comparto al 100% tu punto de vista.

Un saludo.

[gnzsoloyo]

Es cierto que el modelo tiene un par de defectos.

Analicemos:

pre_num --> Es el ID del presupuesto y en una FK referida a la ID de Presupuesto
pre_cod_item --> Es el ID del artículo o item y debería ser una FK referida a una tabla Articulos o Stock
pre_cant_item --> Es un campo de valor único por instancia no repetitivo del registro.
pre_desc_item --> Es un campo de valor único por instancia no repetitivo del registro.
pre_precio_item --> Es un campo de valor único por instancia no repetitivo del registro.
pre_precio_total --> Este campo sí está de más porque es calculable.

Le falta un campo que podríamos definir como:
pre_iditem --> Campo incremental por presupuesto y que identifica el id del item de detalle. El campo se reinicia a valor 1 por cada presupuesto.

En este contexto, la clave primaria de la tabla sería: (pre_num, pre_iditem)

[jchuk]

Ahora sí que he pillado por que es necesaria esta tabla!!!!
Así que cada item es un supuesto "artículo", ok ahora sí, estoy de acuerdo, falta una tabla de artículos o stock o algo así a relacionar con esta.

Es probable entonces del el campo del precio por unidad pudiera pertenecer a esta hipotética tabla de artículos, por ejemplo.
Y el descuento, si es fijo sobre cada item también puede ir en la tabla de artículos, aunque si varía por presupuesto está bien donde está.

Y si el el descuento fuera sobre el total, y no sobre cada item, podría, incluso, ir en la primera tabla como comentaste en el anterior post.

Eres un crack, yo no conseguía ver que representaba cada campo.

Un saludo.

[gnzsoloyo]

Exactamente. Faltaría la definición de la tabla Stock.

Respecto a la presencia del precio unitario en el item, si, es habitual que se tome directamente de la tabla stock, pero si la regla comercial es redondear "a mano", o hacer descuentos directos por artículo, es conveniente que esté. Si solamente se hacen descuentos globales, entonces el porcentaje va en la tabla primaria (Presupuestos).

En cualquier caso, esos detalle tienen que salir del relevamiento del sistema que se está trabajando, o de la consulta de las reglas del negocio en donde se implementará.

[hernino88]

Hola, gracias por responder este post, y disculpen por no haber respondido antes, pero me voy a explicar un poco mejor ya que encontre la solucion...

tengo 3 tablas...

TBL_CLIENTES
cli_id
cli_nombre
cli_direccion
cli_localidad
cli_cp
cli_prov

TBL_PRESUPUESTO
pre_id
pre_fecha
pre_monto_total

TBL_DETALLE
det_pre_id
det_cantidad
det_codigo
det_descripcion
det_precio_uni
det_precio_sub

Entonces que hago con esto...

Por medio del ID de la tabla clientes, levanto los clientes en pantalla y sus datos.

En la tabla TBL_PRESPUESTO, guardo el número del presupuesto (pre_id) la fecha y el monto total en $$$.

Y en la tabla TBL_DETALLE, guardo todo el detalle del presupuesto... Porque hacerlo asi??? porque al guardar datos en una tabla, estos se almacenan como filas, 1 fila sería un presupuesto, pero si el detalle tuviera 10 artículos, el presupuesto debería ocupar 10 filas en la tabla, cosa que no se puede, entonces almaceno tooooodos los detalles de toooodos los presupuestos en una tabla a parte, y los guardo haciendo referencia al número del presupuesto (det_pre_id).

Entonces para levantar el detalle correspondiente a un presupuesto, los selecciono por el campo det_pre_id que coincide con el pre_id...

Ejemplo...

TBL_PRESUPUESTO

pre_id pre_fecha pre_monto_total
01 08/08/08 2300
02 09/08/08 2580
03 10/08/08 3000

TBL_DETALLE

det_pre_id campo2 campo3 campo4
01 xxxxx xxxxx xxxxxx
01 xxxxx xxxxx xxxxxx
01 xxxxx xxxxx xxxxxx
01 xxxxx xxxxx xxxxxx
01 xxxxx xxxxx xxxxxx
02 xxxxx xxxxx xxxxxx
02 xxxxx xxxxx xxxxxx
02 xxxxx xxxxx xxxxxx
02 xxxxx xxxxx xxxxxx
02 xxxxx xxxxx xxxxxx
03 xxxxx xxxxx xxxxxx
03 xxxxx xxxxx xxxxxx
03 xxxxx xxxxx xxxxxx
03 xxxxx xxxxx xxxxxx
03 xxxxx xxxxx xxxxxx


Ya que el pre_id es el numero del presupuesto, el det_pre_id tmb es el numero del presupuesto, lo que significa que todo det_pre_id que coincida con pre_id pretenece a ese presupuesto...

Espero haberme explicado bien...

A ver que opiniones me dan del tema ;)

Saludos.