2011-10-30 15 views

Respuesta

4

Mi respuesta en la publicación vinculada se refiere principalmente a protobuf-net; sin embargo, dado que vienes a esto desde Java, lo recomendaría: mantenlo simple.

Para las fechas, sugiero simplemente usar el tiempo (quizás milisegundos) en una época (el 1 de enero de 1970 es tradicional). Para los tiempos, solo el tamaño en esa misma unidad (milisegundos, etc.). Para decimales, tal vez use un punto fijo simplemente escalando, así que tal vez trate 1.05 como el largo 1050 y afirme siempre exactamente 3dp (de ahí el punto fijo).

Esto es simple y pragmático, y cubre los escenarios más comunes sin complicar las cosas.

+0

Thx ... He seguido tu consejo y hago que los campos de Fecha se representen como "int64" en el archivo proto y lo convertiría en Fecha en mi clase java. – Echo

+0

Eso es lo que hago normalmente, solo almacenemos millis desde la época de Unix. – Jeremy

+0

¿Recomiendas int64 o fixed64? – ticktock

2

No estoy de acuerdo con esta idea, pero estoy realmente no se vendió con la idea de almacenar fechas (que no son instantes en el tiempo) como una marca de tiempo, así que aquí está mi sugerencia.

Convierta su fecha en un número entero legible por el ser humano (por ejemplo, 2014-11-3 se convierte en 20141103) y almacene este valor entero. Contiene exactamente los datos que necesita, es simple de crear y analizar, y ocupa un espacio mínimo. Además, está ordenado y tiene un mapeo uno a uno de las fechas de los valores válidos (se otorgan números no válidos, como 20149999, pero estos son fáciles de detectar). Por el contrario, hay aproximadamente 86400 marcas de tiempo válidas que representan cada día.

NB: Hay un discussion on DBA SE criticando este método de almacenamiento de fecha, pero en ese contexto existe un tipo de fecha especializada, que obviamente no es el caso aquí.

Cuestiones relacionadas