Re: Timestamp como primary key

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