Cita:
Iniciado por Ainner 
Muchas gracias por reponder gnzsoloyo
No se ni por que puse Dia, Mes y Año en columnas distintas, siento un datetime una solucion perfecta, fallo mio.
Pero a esto es a lo que me refiero, teniendo este formato (supongo que es la forma comun de hacer este tipo de cosas), se me quedaria una tabla de este estilo:
Feca_pedido Tipo_pedido Cantidad_pedido Vendedor_id
.2010/05/24..............5.........................15...... ..................1
.2010/05/24..............3..........................8...... ...................1
.2010/05/24..............2..........................3...... ...................1
.2010/05/24..............1.........................12...... ..................1
.2010/05/24..............4.........................18...... ..................1
.2010/05/24..............6..........................3...... ...................1
Mi pregunta viene a ser, que la informacion de la tabla sera muy grande, ya que, la tabla almacenara por cada dia, una cantidad X de pedidos distintos, para todos los comerciales.
Puesto que si tengo 30 vendedores, y 6 tipos de pedidos almacenables (solo los importantes), nos quedaria un total de 180 tuplas por cada dia de la semana que se almacenaran nuevas en la tabla.
Un total de 5580 tuplas al cabo del mes, contando que tenga 31 dias.
No se si se entiende a donde quiero llegar... ¿Tanta informacion, es normal y viable?.
Saludos!.
No sólo es normal y viable. Incluso estás almacenando poca información. Una cantidad casi irrelevante.
Piensa que eso es sólo 180 registros por día. Imagínate lo que se almacena de un sólo punto de venta (caja registradora) en un supermercado en una cadena que tiene una media de 40 por sucursal, en un horario de 08:00 a 21:00 horas, cada día del año...
O simplemente las facturas almacenadas de un local de fotocopias, que atiende 150 clientes al día, con una media de 6 artículos por cliente.
En esos contextos (extremo y muy pequeño), 180 registros de un ancho de 24 bytes cada uno simplemente... es ínfimo.