2010-08-02 19 views
18

Estoy usando SQLite en una aplicación Java a través de Zentus. En este contexto, debo guardar y consultar los valores de Java long en mi base de datos. Procedentes de otros RDBMS he creado la tabla de la siguiente manera para almacenar valores largos:Tipos de datos SQLite

CREATE TABLE myTable (id INTEGER PRIMARY_KEY, longValue LONG) 

Esta solución produce el comportamiento exceptuado pero después de leer la SQLite documentation on data types entendí que mi tipo LONG tiene el mismo efecto que el uso de TEXT =>longValue es almacenado como texto.

Luego decidí cambiar esto a INTEGER (cuya longitud es variable y puede almacenar hasta 64 bits enteros, que es la longitud de Java larga) para tener un código más limpio y puede ahorrar algo de espacio en disco y aumentar performances porque mis longValues ​​se insertan y consultan como long.

Después de comparar las actuaciones y el tamaño de las bases de datos creadas no soy capaz de ver las diferencias entre:

CREATE TABLE myTable (id INTEGER PRIMARY_KEY, longValue LONG) 

y

CREATE TABLE myTable (id INTEGER PRIMARY_KEY, longValue INTEGER) 

Cualquier comentario, experiencias o sentimientos sobre el tema?

Respuesta

22

En SQLite, los tipos de datos son por valor, no por columna. Entonces, cuando insertas enteros, se almacenan como enteros, independientemente del tipo de columna.

+4

Por lo tanto, me pregunto: ¿por qué existen tipos de columnas? –

+9

Las columnas tienen "afinidades"; por ejemplo, una columna de texto a la que se le pasa una cadena numérica debe almacenarla como texto, preservando el formato (lugares decimales, etc.). Mientras que una columna numérica que se pasa una cadena numérica lo convertirá en un número antes de almacenarlo, por lo que "10.00" se devolverá más tarde como solo "10". Como una columna LONG tiene la afinidad numérica predeterminada, cambiar el tipo a INTEGER no cambia nada. –

+3

La respuesta del sitio web SQlite es: "Con el fin de maximizar la compatibilidad entre SQLite y otros motores de base de datos, SQLite admite el concepto de" afinidad de tipos "en las columnas.La afinidad de tipo de una columna es el tipo recomendado para los datos almacenados en esa columna La idea importante aquí es que el tipo es recomendado, no obligatorio. Cualquier columna puede almacenar cualquier tipo de datos. Es solo que algunas columnas, dada la opción, preferirán usar una clase de almacenamiento sobre otra "Pero qué" será preferir "significa? ¿Hay algún impacto en el rendimiento y el tamaño de las bases de datos? –

7

SQLite elige automáticamente el tamaño correcto. De http://www.sqlite.org/datatype3.html:

INTEGER. El valor es un entero con signo, almacenado en 1, 2, 3, 4, 6 u 8 bytes dependiendo de la magnitud del valor.

SQLite utiliza tipos dinámicos y no tiene esquemas.

+0

Gracias por la respuesta rápida Christian. Ya lo leí, y es por eso que estaba pensando que el tamaño de mi base de datos con INTEGER será más pequeño que el que tiene LONG porque la codificación de un largo en "texto" (utf8, creo) debería ser más costosa que usar un entero de longitud variable. no es así? ¿Cómo puedo explicar el mismo tamaño para las 2 bases de datos? –

+0

No es "libre de esquema" en el sentido de los sistemas de bases de datos (claves/valores) NoSQL por supuesto. El primer enlace que di y http: //www.sqlite.org/different.html explica la escritura con más detalle. –

7

Después de mirar actuaciones y tamaño de las bases de datos creadas no soy capaz para ver las diferencias entre:

Hay no es ninguna diferencia. INTEGER tiene afinidad entera y LONG tiene afinidad numérica. Y http://www.sqlite.org/datatype3.html, dice:

Una columna que utiliza afinidad INTEGER se comporta igual que una columna de afinidad con numérico. La diferencia entre INTEGER y afinidad NUMÉRICA solo es evidente en una expresión CAST.

+0

¿Quiere decir que en un modelo numérico funciona como un tipo de "coma flotante"? – Pacerier

2
CREATE TABLE ex2(
    a VARCHAR(10), 
    b NVARCHAR(15), 
    c TEXT, 
    d INTEGER, 
    e FLOAT, 
    f BOOLEAN, 
    g CLOB, 
    h BLOB, 
    i TIMESTAMP, 
    j NUMERIC(10,5) 
    k VARYING CHARACTER (24), 
    l NATIONAL VARYING CHARACTER(16) 
);