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.
- SQLite selecciona todos los registros de hoy y día anterior
- Android - SQLite - SELECCIONAR ENTRE Fecha1 Y Fecha2
- Uso de la memoria sqlite android
- Base de datos SQLite para aplicaciones de Android con múltiples usuarios potenciales
- Cómo concat columnas en Android sqlite
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?
- Java.sql.SQLException: No se puede ejecutar insert stmt en objeto
- Cómo incluir un booleano en una cláusula sql lite where
- SQLITE INSERT con ID manual (clave principal)
- No se pueden actualizar varias filas en el comando de actualización de la base de datos Sqlite en android
- El comodín no funciona en SQLite
- Cómo encontrar y borrar el archivo db de SQLite en Android (emulador)
- Android AsyncTask - una subclase por operación de base de datos?
- Android: ¿ver bases de datos SQLite en el dispositivo?
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.