SQLite: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
No edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Draft}}
<languages />


[https://www.sqlite.org SQLite] is a "pocket database", in that it is a full-featured relational database which however dispenses with the client/server architecture of most such databases and instead exists entirely in a single diskfile. Software in a wide variety of common languages can read from and write to this database file using standard [https://en.wikipedia.org/wiki/SQL SQL] queries using the language's standard API for database interactions, assuming one exists and the database can be transferred to another computer simply by copying the file there.  
<translate>
<!--T:1-->
[https://www.sqlite.org SQLite] is a database management tool used to build commonly called ''pocket databases'' because they offer all the features of relational databases without the client-server architecture and with the added advantage of the data residing on a single disk file which can simply be copied to another computer. Software written in a wide variety of common languages can read from and write to the database file with standard [https://en.wikipedia.org/wiki/SQL SQL] queries using the language's API for database interactions.


==Using SQLite directly==
<!--T:2-->
Like any other database, an SQLlite database should not be used on a shared filesystem such as home, scratch and project. Typically, you should copy your SQLite file to the local scratch <tt>$SLURM_TMPDIR</tt> space at the beginning of a job and you can then use the database without any issues and also enjoy the best possible performance. Note that SQLite is not intended for use with multiple threads or processes writing concurrently to the database; for this you should consider a [[Database_servers | client-server solution]].


==Using SQLite directly== <!--T:3-->
<!--T:4-->
You can access an SQLite database directly using the native client:
You can access an SQLite database directly using the native client:
{{Command|sqlite3 foo.sqlite}}
{{Command|sqlite3 foo.sqlite}}
If the file <tt>foo.sqlite</tt> does not already exist, the SQLite software will create it and the client starts in an empty database, otherwise you are connected to the existing database. You may then execute whichever queries you wish on the database, such as <tt>SELECT * FROM tablename;</tt> to print to the screen the entire contents of the table <tt>tablename</tt>.
If the file <tt>foo.sqlite</tt> does not already exist, SQLite will create it and the client will start in an empty database, otherwise you will be connected to the existing database. You may then execute whichever queries you wish on the database, such as <tt>SELECT * FROM tablename;</tt> to print to the screen the entire contents of the table <tt>tablename</tt>.  


==Accessing SQLite from software==


This most common way of interacting with an SQLite (or other) database is programmatically, i.e. inside of a program written in one of various languages like [[R]] or [[Python]], using a series of function calls to open a connection to the database, execute queries that can read or update existing data in the database as well as inserting new data and finally close the connection to the SQLite database.
==Accessing SQLite from software== <!--T:5-->


<!--T:6-->
The most common way to interact with an SQLite (or other) database is through function calls to open a connection to the database; execute queries that can read, insert or update existing data; and close the connection to the SQLite database so that any changes are flushed to the SQLite file. In the simple example below, we suppose that the database has already been created with a table called <tt>employee</tt> that has two columns: the string <tt>name</tt> and the integer <tt>age</tt>.
</translate>
<tabs>
<tabs>
<tab name="Python">
<tab name="Python">
Line 22: Line 31:
import sqlite3
import sqlite3


age = 34
# Connect to the database...
dbase = sqlite3.connect("foo.sqlite")
dbase = sqlite3.connect("foo.sqlite")
crs = dbase.cursor()
params = ("employees",)
crs.execute("SELECT * FROM ?;",params)
rows = crs.fetchall()
for r in rows:
    print(r)


dbase.execute("INSERT INTO employee(name,age) VALUES(\"John Smith\"," + str(age) + ");")
# Close the database connection
dbase.close()
dbase.close()
</source>
</source>
Line 38: Line 47:
# after which you can use code like the following to interact with the SQLite database
# after which you can use code like the following to interact with the SQLite database
library(DBI)
library(DBI)
age <- 34


# Connect to the database...
# Connect to the database...
Line 43: Line 54:


# A parameterized query
# A parameterized query
rs <- dbSendQuery(dbase,"SELECT * FROM tname",params = list(tname = "employees"))
query <- paste(c("INSERT INTO employee(name,age) VALUES(\"John Smith\",",toString(age),");"),collapse='')
while (!dbHasCompleted(rs)) {
dbExecute(dbase,query)
  # Grab a maximum of ten rows at a time...
  df <- dbFetch(rs,n = 10)
  # Print the number of rows we actually got from dbFetch
  print(nrow(df))
}
dbClearResult(rs)


# Close the database connection
# Close the database connection
Line 58: Line 63:
<tab name="C++">
<tab name="C++">
<source lang="cpp">
<source lang="cpp">
#include <iostream>
#include <string>
#include <string>
#include <sqlite3.h>
#include <sqlite3.h>
Line 63: Line 69:
int main(int argc,char** argv)
int main(int argc,char** argv)
{
{
  int age = 34;
   std::string query;
   std::string query;
   sqlite3* dbase;
   sqlite3* dbase;


   sqlite3_open("foo.sqlite",&dbase);
   sqlite3_open("foo.sqlite",&dbase);
   query = "SELECT * FROM " + std::string(argv[1]) + ";";
 
   query = "INSERT INTO employee(name,age) VALUES(\"John Smith\"," + std::to_string(age) + ");";
   sqlite3_exec(dbase,query.c_str(),nullptr,nullptr,nullptr);
   sqlite3_exec(dbase,query.c_str(),nullptr,nullptr,nullptr);
   sqlite3_close(dbase);
   sqlite3_close(dbase);


Line 76: Line 85:
</tab>
</tab>
</tabs>
</tabs>
<translate>
==Limitations== <!--T:7-->


==Caveats==
<!--T:8-->
As its name suggests, SQLite is easy to use and intended for relatively simple databases which are neither excessively large (hundreds of gigabytes or more) nor too complicated in terms of their [https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model entity-relationship diagram]. As your SQLite database grows in size and complexity, the performance could start to degrade, in which case the time may have come to consider the use of more [[Database_servers | sophisticated database software which uses a client-server model]]. The SQLite web site includes an excellent page on [https://www.sqlite.org/whentouse.html Appropriate Uses For SQLite], including a checklist for choosing between SQLite and client-server databases.


SQLite is as the name suggests easy to use and intended for relatively simple databases and which are neither excessively large (hundreds of gigabytes or more) nor too complicated in terms of their [https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model| entity-relationship diagram]. As your SQLite database grows in size and complexity the performance could start to degrade, in which case the time may have come to consider the use of more [[Database_servers | sophisticated database software which uses a client/server model]].  The SQLite web site includes an excellent page on [https://www.sqlite.org/whentouse.html Appropriate Uses For SQLite], including a checklist for choosing between SQLite and client/server databases.
</translate>

Latest revision as of 19:47, 12 March 2020

Other languages:

SQLite is a database management tool used to build commonly called pocket databases because they offer all the features of relational databases without the client-server architecture and with the added advantage of the data residing on a single disk file which can simply be copied to another computer. Software written in a wide variety of common languages can read from and write to the database file with standard SQL queries using the language's API for database interactions.

Like any other database, an SQLlite database should not be used on a shared filesystem such as home, scratch and project. Typically, you should copy your SQLite file to the local scratch $SLURM_TMPDIR space at the beginning of a job and you can then use the database without any issues and also enjoy the best possible performance. Note that SQLite is not intended for use with multiple threads or processes writing concurrently to the database; for this you should consider a client-server solution.

Using SQLite directly

You can access an SQLite database directly using the native client:

Question.png
[name@server ~]$ sqlite3 foo.sqlite

If the file foo.sqlite does not already exist, SQLite will create it and the client will start in an empty database, otherwise you will be connected to the existing database. You may then execute whichever queries you wish on the database, such as SELECT * FROM tablename; to print to the screen the entire contents of the table tablename.


Accessing SQLite from software

The most common way to interact with an SQLite (or other) database is through function calls to open a connection to the database; execute queries that can read, insert or update existing data; and close the connection to the SQLite database so that any changes are flushed to the SQLite file. In the simple example below, we suppose that the database has already been created with a table called employee that has two columns: the string name and the integer age.

#!/usr/bin/env python3

# For Python we can use the module sqlite3, installed in a virtual environment, 
# to access an SQLite database
import sqlite3

age = 34

# Connect to the database...
dbase = sqlite3.connect("foo.sqlite")

dbase.execute("INSERT INTO employee(name,age) VALUES(\"John Smith\"," + str(age) + ");")

# Close the database connection
dbase.close()
# Using R, the first step is to install the RSQLite package in your R environment, 
# after which you can use code like the following to interact with the SQLite database
library(DBI)

age <- 34

# Connect to the database...
dbase <- dbConnect(RSQLite::SQLite(),"foo.sqlite")

# A parameterized query
query <- paste(c("INSERT INTO employee(name,age) VALUES(\"John Smith\",",toString(age),");"),collapse='')
dbExecute(dbase,query)

# Close the database connection
dbDisconnect(dbase)
#include <iostream>
#include <string>
#include <sqlite3.h>

int main(int argc,char** argv)
{
  int age = 34;
  std::string query;
  sqlite3* dbase;

  sqlite3_open("foo.sqlite",&dbase);

  query = "INSERT INTO employee(name,age) VALUES(\"John Smith\"," + std::to_string(age) + ");";
  sqlite3_exec(dbase,query.c_str(),nullptr,nullptr,nullptr);

  sqlite3_close(dbase);

  return 0;
}

Limitations

As its name suggests, SQLite is easy to use and intended for relatively simple databases which are neither excessively large (hundreds of gigabytes or more) nor too complicated in terms of their entity-relationship diagram. As your SQLite database grows in size and complexity, the performance could start to degrade, in which case the time may have come to consider the use of more sophisticated database software which uses a client-server model. The SQLite web site includes an excellent page on Appropriate Uses For SQLite, including a checklist for choosing between SQLite and client-server databases.