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.
I'm a bit of a Drupal newbie but have committed myself to porting some quite complex bespoke websites.
One of these is a surf report site which uses a database with millions of time/location rows to get the local conditions. Obviously can't write this to a Drupal table everyday so am looking for a way to connect and retrieve live data.
I'll need to use the external data in a number of displays which would normally be nodes, views, blocks etc.
The ideal solution would be if the external data just appeared as local data, but I'm guessing that is a rather big ask.
I'm open to any approach. If it involves writing a module some pointers on what to look at (preferably code examples) would be much appreciated.
Thanks,
Chris
Maybe you can use the Data module.
From the documentation:
The Data module lets you use database tables that are foreign to Drupal.
You can 'adopt' a table in your database that ordinarily Drupal would not be aware of. This might be external data you have imported, or a table that another application has created.
It also provides Views integration.
I had to show info from a legacy staff databse in my Drupal 6. I have explored three ways:
Importing database rows as nodes in a nightly cronjob
Accessing the external database in my own module
Accessing the external database using hook_views_data()
If I started again I would use hook_views_data(), it's more flexible, specially if you want to match the external database information with drupal nodes.
Best.
Have a look at the Forena module which can be used to display (= query, not update) data stored in databases external to Drupal. It comes with a full suite of Supported database connections, such as MySQL, MS SQL, Oracle, Postgres or any PDO compliant variation.
For more details about Forena, 2 types of documentation are available:
Community documentation.
Documentation that comes with Forena, which you can access right after install and enable of the module. Checkout the demo site for an online example of the Forena Documentation.
The Sample reports and graphs are fully functional, such as the drill downs available on the Master Summary with drill down. Using Forena "skins", you can also use the amazing "dataTables" (and its widgets, such as sorting by selected columns).
Forena also includes a UI for either creating your reports (the WYSIWYG Report Editor) and/or for creating your SQL queries (the WYSIWYG Query Builder).
Disclosure: I'm a co-maintainer of Forena.
I want to develop a PHP application. And I don't want to use MySQL for my application. And I will need full-text search feature for my application. I want to know that which database is best for my needs, Flat file or SQLite database for full-text search. Please suggest me some advantages and disadvantages for both databases.
If you have to ask, sqlite is better. It works and is fast.
The advantage of using a flat-file over it is that you have no dependencies on sqlite. The disadvantages of using it is that you don't have any indexes built in, so all queries will be slower. It will take a lot of effort to develop it and make sure it is bug free.
I am looking for a good change management application for use with SQLite. In the past I have used SQL Data compare by Redgate, but I have been unable to find anything similar that supports SQLite.
I need to update a fairly large encrypted SQLite database (~1,000,000 rows and 74MB). If possible I would like to generate some scripts to just update the changes rather than force users to download a whole new copy of the database. The version of SQLite we are using is 3.6.23.1. Thanks in advance for any recommendations :)
Have you tried SQLite Compare? It's freeware, and I have used it to compare schemas/data. I think it will also generate SQL update scripts for you too.
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.