Jorge Romeo escribió: > > Hola, os contesto a Alvaro y Emanuel : > > @ Alvaro > > > se me ocurre que es incorrecto usar sólo el timestamptz como llave > > primaria; debería llevar además el identificador de la máquina que > > genera el dato, ¿no? Actualmente estás limitado por el sistema de > > comunicación, pero no es impensable que algún día le enchufes otro > > puerto serial y tengas un flujo doble de datos, algunos de los cuales > > van a tener las mismas horas ... > > El identificador de la máquina va dentro de la trama en bruto. Si lo > introduzco tendré información redundante. Podría hacer que la PK fuera > (fecha, trama), aunque algo me dice que no lo haga.
Puede que sea redundante, pero a mí me parece que la trama en bruto es un derivado de la llave primaria que es (id, fecha). Si lo ves de esa forma, el dato redundante es el de la trama, no el de la llave :-) La otra llave que propones no tiene sentido, porque la trama contiene más datos que los estrictamente necesarios para indicar unívocamente un registro. > No es impensable que haya más flujo de datos, de hecho las máquinas > nuevas nos vendrán por ethernet, por lo que el flujo podría ser mil > veces mayor, al menos teóricamente. Esto haría además que unos pocos > bytes de más resultaran en cientos de MB en no mucho tiempo lo cual es > más carga para la BD (el espacio en sí no es caro a día de hoy). Como tú dices, el espacio no es problema, pero en cuanto la limitación de 9600bps desaparezca vas a tener problemas de diseño severos si tu llave no es correcta. > La pregunta que se me ocurre ahora es si Postgres perderá rendimiento > si le pongo un campo más, digamos un byte (75 es el máximo de máquinas) > para identificar mejor las tramas. Tambíen hay que contar que las búsquedas > se suelen hacer por máquina por lo que no sería mucha desventaja. Tienes que tener mucho cuidado con las consideraciones de alineamiento al escoger la estructura de la tabla; de lo contrario, los bytes que ahorres por usar tipos de datos muy estrechos los estarás perdiendo en alineamiento. No tengo tiempo de explayarme más en este momento; busca por "tuple alignment". Quizás en el wiki haya algún artículo que lo explique. (Otra cosa a considerar es que quizás te convenga tener un tipo de dato específico para la trama en bruto, que quizás pueda ser más eficiente que bytea). -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "This is what I like so much about PostgreSQL. Most of the surprises are of the "oh wow! That's cool" Not the "oh shit!" kind. :)" Scott Marlowe, http://archives.postgresql.org/pgsql-admin/2008-10/msg00152.php -- TIP 4: No hagas 'kill -9' a postmaster
