tags:

views:

89

answers:

3
+3  Q: 

SQLite Data Types

Hi all,

I am using SQLite in a Java application through Zentus. In this context I need to save and queries Java long values in my database. Coming from other RDBMS I created table as following to stor long values:

CREATE TABLE myTable (id INTEGER PRIMARY_KEY, longValue LONG)

This solution produces the excepted behavior but after reading the SQLite documentation on data types I understood that my LONG type has the same effect than using TEXT => My longValues are stored as text.

I then decided to change this to INTEGER (which length is variable and can store up to 64 bits integers which is the length of Java long) in order to have cleaner code and may be to save some disk space and to increase performances because my longValues are inserted and queried as long.

After looking at performances and size of the created databases I am not able to see any difference between:

CREATE TABLE myTable (id INTEGER PRIMARY_KEY, longValue LONG) and

CREATE TABLE myTable (id INTEGER PRIMARY_KEY, longValue INTEGER)

Any comments, experiences or feelings on the subject ??

Thanks in advance

Manu

+2  A: 

SQLite chooses automatically the right size. From http://www.sqlite.org/datatype3.html:

 INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes
 depending on the magnitude of the value.

SQLite uses dynamic types and is schema free.

Christian Ullenboom
Thanks for the quick answer Christian. I already read that, and it's why I was thinking that my database size with INTEGER will be smaller than the one with LONG because encoding a long in "text" (utf8 I think) should be more expensive than using variable length integer. isn't it ? How can I explain the same size for the 2 databases ?
Manuel Selva
@Christian Ullenboom - schema free??
sheepsimulator
Not "schema free" in the meaning of NoSQL databases (key/values) systems of course. The first link I gave and http://www.sqlite.org/different.html explains the typing in more detail.
Christian Ullenboom
+3  A: 

In SQLite, data types are per-value, not per-column. So when you insert integers, they're stored as integers regardless of the column type.

Tangent 128
Thus I am wondering: why column types exist ?
Manuel Selva
Columns have "affinities"; for instance, a text column that gets passed a numeric string should store it as text, preserving the formatting (decimal places, etc).Whereas a numeric column that is passed a numeric string will convert it to a number before storing it, so "10.00" would be later returned as just "10".Since a LONG column has the default numeric affinity, changing the type to INTEGER doesn't change anything.
Tangent 128
The answer fron SQlite web site is: "In order to maximize compatibility between SQLite and other database engines, SQLite supports the concept of "type affinity" on columns. The type affinity of a column is the recommended type for data stored in that column. The important idea here is that the type is recommended, not required. Any column can still store any type of data. It is just that some columns, given the choice, will prefer to use one storage class over another" But what "will prefer" means ?? Is there any impact on performances and databases sizes ?
Manuel Selva
@Tangent, many thanks for your help. One more question, I was thinking LONG columns having TEXT affinity. Where did you get the affinity for LONG columns, in a web document or is it possible to ask it to sqlite ?
Manuel Selva
LONG isn't recognized by SQLite, but section 2.1 in the datatype documentation says that unrecognized types default to numeric.
Tangent 128
+1 again for your help. Thanks. Manu
Manuel Selva
+1  A: 

After looking at performances and size of the created databases I am not able to see any difference between:

There isn't any difference. INTEGER has integer affinity and LONG has numeric affinity. And, http://www.sqlite.org/datatype3.html says:

A column that uses INTEGER affinity behaves the same as a column with NUMERIC affinity. The difference between INTEGER and NUMERIC affinity is only evident in a CAST expression.

dan04