While SQLite is for relationnal database, how couchbase use it for NoSQL data queryable ?
Couchbase Lite can use different storage engines internally.
In the SQLite case, the main document body is stored as a blob. Most of the data in the tables actually has to do with tracking revisions, views, supporting sync (replication), and so on. (This is as of version 1.4.0.)
So, to answer what I think is the main point of your question, CBL isn't turning documents into tables the way you would if you were trying to store the data directly in SQLite.
These are, of course, implementation details you should not rely on. If you're interested in finding out more, you can look at the source (Couchbase is open source) and use standard SQLite tools to examine the database itself.
Can BLOB (or any other data) be compressed (on the fly) into an SQLite3 database?
I'm using System.Data.SQLite in C# targeting .net 3.5.
In my search I keep seeing connection strings like so...
"datasource=base.db;version=3;compress=true;"
But I can find no information about compress=true, I've added it to my connection string for testing and added file as BLOB data but there appears to be no compression, I have tested with for example a large text file, so not an already compressed image or other file.
To my very limited knowledge, the "compress=True" parameter in the System.Data.SQLite.SQLiteConnection String is not taken in account.
Basically, it is kind of useless: there is no built-in compression provided for the .NET System.Data.SQLite.
In order to bring some compression features to the System.Data.SQLite world, you have basically have two options:
Using some third party tools, whether by including among one of those C libraries and rebuilding the System.Data.SQLite based on it: Proprietary SQLite Extensions: SEE, CEROD, ZIPVFS / SQLite Crypt / etc. The commercial ORM Devart based on ADO.NET offers the support for the encryption options I just mentioned and seems they can be used seamlessly (although I personally never tried to use Devart that much).
Creating a wrapper around the System.Data.SQLite: whether converting all your data with some headers about the encapsulated data are and inserting everything using some collection of bytes with a blob data affinity. You can also by the way provide at the same time some additional encryption process.Of course, this will be (much) slower than the C third-party libraries available and may be not sufficient depending on your requirements (insertions, updates,.., deletions speed), but at least this is free (and time-consuming) approach. This can be achieved through a specific SQLite ORM, should not be that hard to implement but quite time-consuming.
I'm trying to use TideSDK to create a Accounting software for a client.
The software will mainly do CRUD operations.
I'm wondering which Database is shipped with TideSDK. Is it localStorage / SQLite?
Is there a way to bundle any other Database?
The reason I'm asking is, the software will store around 10 tables and each with approx 10K rows min (depends on user's plan).
What's the best way to take regular backup so we don't loose any data in case Database crashes?
TideSDK is shipped with SQLite Database. There is no limitation for the database size for the SQLite Database, as long as you have enough harddisk space you should be able to use and expand the database.
You can certainly bundle any other database with TideSDK application. Currently the natively supported database is SQLite.
Say I wanted to build a feed reader that downloads RSS and Atom feeds to your local computer and lets you view them locally. What are the respective advantages and disadvantages of using CouchDB or sqlite3 as the datastore for such an application?
SQLite and CouchDB are probably different in every respect but what you consider an advantage or disadvantage is a matter of preference and requirements.
SQLite is an SQL database where you store relations (tables).
CouchDB is a NoSQL database where you store JSON documents (objects of any structure).
SQLite has schemas.
CouchDB is schema-less.
SQLite is a library that you link with your application and use a C API.
CouchDB is a RESTful web service and its API is HTTP and JSON.
SQLite has no concept of a network.
CouchDB basically is a high performance web server.
SQLite is written in C.
CouchDB is written in Erlang.
Which of those are advantages and disadvantages? This is up to you. ;) Good luck.
Good summary from rsp. Without knowing more about your requirements, it's hard to say which one is better suited for your use case. One clear advantage that SQLite provides is that is has simpler installation and administration. As a library, it's linked into your application and installed along with your application. No separate database to install and configure. This is one of the features that makes database libraries, like SQLite and Berkeley DB very attractive, and possibly preferable to database servers.
Just to add to your list of considerations, Berkeley DB and Berkeley DB Java Edition are also database libraries that you may want to consider. Berkeley DB (written in C) offers you the choice of using a schema-free key-value pair API, a POJO-like Java API or a SQLite-compatible SQL API. Berkeley DB Java Edition (100% Java) offers you Java APIs for key-value pairs, Java Collections or POJO-like object persistence. Berkeley DB and SQLite tend to be the products of choice for people who are looking for embedding data management functionality inside of their application.
Disclaimer: I am the Product Manager for Berkeley DB, so I'm a little biased. :-)
I don't know how authoritative this is but I found this:
http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations
and it doesn't seem good to have a lot of connections to sqlite. This seems to be bad for the web and most applications that have more than a few users. I'm having a hard time thinking of what sqlite would be used for when you don't need that many connections. Every program I can think of needs users, lots of them sometimes, so what would I use a database for that doesn't allow that many connections? I thought about prototypes but why would I use that when I can just connect to a larger database? Embedded apps maybe?
Thank you.
EDIT: Thanks everyone. I look at the page recommended below but an confused about something:
Under appropriate uses for sqlite it has:
Situations Where SQLite Works Well
•Websites
SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.
Situations Where Another RDBMS May Work Better
•Client/Server Applications
If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.
A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem.
The Question:
I'm going to show my ignorance here but what is the difference between these two?
This is answered well by sqlite itself : Appropriate use of sqlite
Another way to look at SQLite is this:
SQLite is not designed to replace Oracle. It is designed to replace fopen().
It's good for situations where you don't have access to a "real" database and still want the power of a relational db. For example, Firefox stores a bunch of information about your settings/history/etc in an SQLite database. You can't expect everyone that runs firefox to have MySQL or postgre installed on their machine.
It's also perfectly capable of running relatively-low traffic, read-heavy websites. The performance of it is overall very good, it's more than the large majority of websites need for their traffic levels.
It's often used for embedded applications.
It can be very handy to use a database like storage when you have no access to a database service. So SQLite is used since it's just a file you store somewhere.
I also find that using SQLite is good for getting a prototype application together pretty quickly without the overhead of having a seperate DB server or bogging a development environment with an instance of MySQL/Oracle/Whatever.
Also easy to pick up and move the database to a different machine if you need to.
The iPhone uses it for call history, SMS messages, contacts, and other type of data. Like Ólafur Waage said, good for embedded applications on mobile device because it's lightweight. I have used it also on stand alone applications. Easy to use and available on most platforms.
Think about simple client or desktop apps that could make use of a db, like as a poor example, an address book. Rather than bundling a huge db engine like mysql or postgre with your deliverable, sqlite is very lightweight and easy to include with your finished app.
This FLOSS Weekly podcast episode talks with the creator of SQLite and covers among other things goes over the type of things you would use it for. Everything from file systems for mobile phones to smallish web sites.
In the simplest terms, SQLite is a public-domain software package that provides a
relational database management system, or RDBMS. Relational database systems are
used to store user-defined records in large tables. In addition to data storage and management,
a database engine can process complex query commands that combine data
from multiple tables to generate reports and data summaries. Other popular RDBMS
products include Oracle Database, IBM’s DB2, and Microsoft’s SQL Server on the
commercial side, with MySQL and PostgreSQL being popular open source products.
The “Lite” in SQLite does not refer to its capabilities. Rather, SQLite is lightweight
when it comes to setup complexity, administrative overhead, and resource usage.
For detail info and solution about SQLite visit the link below:
http://blog.developeronhire.com/what-is-sqlite-sqlite/
Thank you.
What the above two answers say. Expanding slightly on Chad Birch's answer, its teh calls to the SQLite db, and a rather poor implementation of sync() that causes FF3 to be so slow in linux.