Cómo almacenar datetime en SQLite

Esto es muy similar a otra pregunta que se cerró como no una pregunta real. Intenté editarlo para que fuera válido para la reapertura, pero me dijeron que sería mejor preguntar una nueva pregunta.

Estoy desarrollando en android y necesito almacenar valores de fecha y hora en una base de datos sqlite para rastrear eventos repetitivos que generarán notificaciones. También necesitaré poder consultar la base de datos basada en intervalos de tiempo.

La documentación de SQLite indica que no admite tipos de fecha específicos, pero que las fechas se pueden representar con los tipos TEXT, REAL o INTEGER:

TEXT como cadenas ISO8601 ("AAAA-MM-DD HH: MM: SS.SSS").

REAL como números de día Juliano, el número de días desde el mediodía en Greenwich el 24 de noviembre de 4714 aC de acuerdo con el proleptico calendario gregoriano.

INTEGER como Unix Tiempo, el número de segundos desde 1970-01-01 00:00:00 UTC.

Las ventajas de cada una parecen inicialmente ser:

  • TEXTO útil para la legibilidad en la base de datos con capacidad de ser mostrada directamente más adelante (ninguna transformación necesaria), pero costoso si los cálculos necesitan ser realizados en ellos. Introduce el posible error de las zonas horarias.
  • REAL útil para fechas antes de 1970, bueno para cálculos o comparaciones de fechas. No representa la hora del día, sólo días.
  • INTEGER útil para cálculos o comparaciones de fecha y hora, muy buena compatibilidad ya que es un estándar ampliamente apoyado.

¿Este sonido es correcto? ¿Utilizar un INTEGER para datetimes hace que los intervalos de tiempo de consulta sean notablemente más rápidos que cuando se utiliza TEXT? ¿Algo más que no he considerado?

Dado mi caso de uso, ¿cuál de estas soluciones sería mejor?

TEXTO útil para la legibilidad en la base de datos con capacidad de ser mostrada directamente más adelante (ninguna transformación necesaria)

Normalmente, el formato ISO no se utiliza para la visualización; Usted tiene que transformar esto, también. (Este formato es más útil para la depuración.)

Costoso si los cálculos necesitan ser realizados en ellos

Con las bases de datos, el cuello de botella suele ser la E / S. Dudo que alguna vez vea una consulta donde el formato real de los valores de fecha haría una diferencia notable.

Introduce el posible error de las zonas horarias.

El formato TEXTO no tiene un especificador de zona horaria, pero tampoco tienen los otros formatos. Si usted dice que todos sus valores de DB están en UTC, no hay diferencia.

REAL útil para fechas anteriores a 1970

Todos los formatos admiten todos los años entre 0 y 9999. (Los enteros pueden ser negativos.)

No representa la hora del día, sólo días.

La hora del día se representa como un valor fraccionario.

INTEGER … muy buena compatibilidad ya que es un estándar ampliamente apoyado.

Pero Java utiliza milisegundos, no segundos.

¿Algo más que no he considerado?

El formato de salida predeterminado de la mayoría de las funciones de fecha incorporadas es TEXTO.


Dado mi caso de uso, ¿cuál de estas soluciones sería mejor?

Yo diría TEXTO, pero no creo que hubiera mucha diferencia.

Las respuestas aquí van a ser principalmente la opinión, pero si yo fuese usted, usaría el tipo INTEGER y almacenaría la marca de tiempo unix. Parece menos dependiente de las conversiones de formato / análisis, y es el estándar más compatible universalmente.

No representa la hora del día, sólo días.

Eso es lo que la parte fraccionaria de la REAL es para.

¿Utilizar un INTEGER para datetimes hace que los intervalos de tiempo de consulta sean notablemente más rápidos que cuando se utiliza TEXT?

Más probable. No puedo imaginar un escenario en el que las comparaciones de cadenas sean más rápidas que las comparaciones de enteros, en particular para las columnas indexadas en las consultas.

¿Algo más que no he considerado?

No tengo idea de si se han considerado los efectos de los rayos gamma sobre las caléndulas hombre-en-la-luna , pero eso no es importante aquí. Todos los derechos reservados

Dado mi caso de uso, ¿cuál de estas soluciones sería mejor?

INTEGER , IMHO.

Almacene la hora de la fecha UTC como entero de 64 bytes de 8 bytes en SQLite. Millis sence 1970.

 long time= System.currentTimeMillis(); 

Con una base de datos indexada tendrá una excelente respuesta para alrededor de 10k filas en orden por y entre los datos de lectura de fecha y hora.

Deje las manipulaciones de zona horaria a la capa de vista porque una base de datos con todas las horas UTC funcionará en todo el mundo.

No almacene fechas como texto que es tan antiguo y no tiene lugar en una aplicación moderna.

Evitaría de almacenar apenas las fechas porque las aplicaciones modernas toman en cuenta cuando ocurrió un acontecimiento. Puede almacenar fechas con 8 bytes. Pero si usted debe usted puede poner simplemente la fecha del iso en un entero 1999-12-31 como 19991231 y almacenar un entero de 4 bytes en sqllite.

  • No es posible obtener datos de la base de datos Sqlite
  • Problemas en la creación de varias tablas en sqlite
  • Los ejemplos de ORMLite para Android no compilarán
  • Android SQLiteAssetHelper No se puede actualizar la base de datos de sólo lectura de la versión 1 a 2:
  • ¿Cuál es la sintaxis de "no igual" en SQLite?
  • Problema con SQLiteOpenHelper en android 2.X y 3.X
  • Random () en sqlite y Android sdk
  • Android.database.sqlite.SQLiteException: la tabla X no tiene columna llamada Y:, mientras compila: INSERT INTO
  • ¿Qué tan rápido es cursor.moveToPosition (i)?
  • ¿Cuál es el modo de subprocesamiento predeterminado de SQLite en Android?
  • Cómo utilizar la conexión SQLite desde la carpeta de activos
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.