锘??xml version="1.0" encoding="utf-8" standalone="yes"?>
鐗規(guī)у拰灞闄愭?/font>
In this section we will look at the key features of SQLite and some of its limitations. The nature of SQLite makes it an ideal choice for quite a number of tasks, but it's not suitable for everything.
鍦ㄦ湰閮ㄥ垎鎴戜滑灝嗚鐪嬩竴涓婼QLite鍏抽敭鐗規(guī)у拰瀹冪殑涓浜涘眬闄愭с係QLite鐨勬湰璐ㄤ嬌瀹冩垚涓鴻澶氫換鍔$殑鐞嗘兂閫夋嫨錛屼絾瀹冨茍涓嶉傚悎鎵鏈夌殑鏂歸潰銆?br />
閫熷害
SQLite is extremely efficient, benefiting from a highly optimized internal architecture and a small memory footprint. Because SQLite is not a client/server database, the overheads of running a database daemon and socket communication are eliminated.
SQLite 闈炲父楂樻晥錛岃繖寰楃泭浜庨珮搴︿紭鍖栫殑鍐呴儴緇撴瀯鍜屽緢灝忕殑鍐呭瓨闇姹傘傚洜涓篠QLite 涓嶆槸涓涓鎴風(fēng)/鏈嶅姟鍣ㄧ被鍨嬬殑鏁版嵁搴擄紝榪愯涓涓暟鎹簱榪涚▼鍜屽鎺ュ瓧閫氫俊鐨勫紑閿琚秷闄や簡銆?br />
鍦?/font>
http://www.sqlite.org/speed.html
涓婄殑鍙戣〃浜嗗畠鍜孧ySQL鍜孭ostgreSQL閫熷害瀵規(guī)瘮銆傚姣旇〃鏄庯紝SQLite鍦ㄦ墽琛屾櫘閫氭搷浣滅殑鏃跺欓熷害姣擯ostgreSQL蹇?0鍊嶏紝鏄疢ySQL鐨勪袱鍊嶃?/font>
榪欎釜鏄湪姣忎釜鏁版嵁搴撶殑榛樿瀹夎鎯呭喌涓嬫祴璇曠殑錛屽敖綆″湪緇欏畾鐨勭幆澧冧腑璋冩暣涔嬪悗錛孧ySQL鍜?PostgreSQL 鐨勬墽琛屾儏鍐典細(xì)鐣ユ湁鎻愰珮錛屼絾鏄疭QLite鏄笉闇瑕佷換浣曚紭鍖栫殑銆?/font>
縐繪鎬?/font>
Because SQLite databases are stored as single files on the filesystem, they are very portable indeed. A database can be copied from one file to another, even across different operating systems. This means that for a cross-platform distribution you just need to concentrate on making your code portable even when a populated database is to be shipped with the application.
鍥犱負(fù)SQLite鏁版嵁搴撳湪鏂囦歡緋葷粺涓婃槸浣滀負(fù)鍗曚釜鏂囦歡瀛樺偍鐨勶紝瀹為檯涓婂畠浠槸闈炲父瀹規(guī)槗縐繪鐨勩備竴涓暟鎹簱鍙浠庝竴涓枃浠舵嫹璐濆埌鍙︿竴涓枃浠訛紝鐢氳嚦鏄法瓚婁笉鍚岀殑鎿嶄綔緋葷粺銆傝繖鎰忓懗鐫鍦ㄦ湁涓涓氦鍙夊鉤鍙頒笂鍙戝竷鐨勬椂鍊欙紝浣犲彧闇瑕佸叧娉ㄤ簬浣夸綘鐨勪唬鐮?浣垮叾鍙互縐繪錛岀敋鑷蟲槸褰撲竴涓彲縐繪鐨勬暟鎹簱鏄拰搴旂敤涓璧峰彂甯冪殑銆?/font>
SQLite databases are stored to the filesystem and access control is performed by the underlying operating system based on that file's permission settings.
Though SQLite can be accessed by processes running as different users if the correct file permissions are set, the database engine does not detect which user is performing a particular operation.
濡傛灉姝g‘鐨勬枃浠惰闂潈闄愯瀹氫簡錛屽敖綆QLite鑳藉閫氳繃榪涚▼榪愯浣滀負(fù)涓嶅悓鐨勭敤鎴鋒潵琚闂紝浣嗘槸鏁版嵁搴撳紩鎿庡茍涓嶆嫻嬪摢涓敤鎴鋒鍦ㄦ墽琛屼竴涓壒鍒殑鎿嶄綔銆?/font>
瀹冪殑浼樼偣涔嬩竴灝辨槸綆$悊綆鍗曪紝涓嶉渶瑕佽瀹氬鏉傜殑鐢ㄦ埛鎺堟潈妯″紡銆備換浣曟嫢鏈夎闂潈鍒╃殑鐢ㄦ埛閮藉彲浠ヨ闂暟鎹簱琛ㄦ牸鍜岃褰曘傚悓鏍鳳紝鍦ㄤ竴涓叡浜幆澧冧腑錛岀敤鎴峰彲浠ュ湪浠栦滑鐨勮嚜宸辯殑鏂囦歡絀洪棿涓婂垱寤轟粬浠嚜宸辯殑SQLite鏁版嵁搴撹屼笉鐢ㄦ秹鍙婄郴緇熺鐞嗐?/font>
SQL宸ュ叿
SQLite supports a large subset of the ANSI SQL-92 standard. Some features have a limited implementation and a few features are not supported at all.
SQLite鏀寔ANSI SQL-92鏍囧噯鐨勫ぇ鐨勫瓙闆嗐傛煇浜涚壒鎬ф湁涓涓湁闄愮殑宸ュ叿錛屽叾浠栦竴浜涚壒鎬у茍涓嶉兘琚敮鎸併?/font>
渚嬪錛屽師瀛愪簨鍔℃槸鍙敤鐨勶紝浣嗕笉鑳藉祵濂楋紱綆鍗曠殑瀛愭煡璇㈡槸鍙互鐨勶紝浣嗙浉浜掑叧鑱旂殑瀛愭煡璇㈡槸涓嶈鐨勶紱瑙﹀彂鍣ㄥ彲浠ュ湪姣忎竴琛岃Е鍙戯紝浣嗕笉鑳藉湪姣忎釜璇彞涓婅Е鍙戯紱瑙嗗浘鏄彲瑙佷絾鏄彧璇葷殑銆?br />The list of current limitations is maintained at
http://www.sqlite.org/omitted.html
with the items at the top of the list indicating which items are most likely to be added to SQLite first.
鐩墠琚淮鎶ょ殑灞闄愭у垪琛ㄥ湪
http://www.sqlite.org/omitted.html
涓婏紝鍒楄〃鐨勪笂閮ㄧ殑閫夐」鎸囩ず浜嗗摢浜涢夐」鏈鏈夊彲鑳借鍏堝姞鍏ュ埌SQLite
瀹氬埗
The SQLite library includes a very powerful mechanism for adding user-defined functions to the SQL command set. Custom functions can even be written in many of the supported language APIs, not just C/C++.
聽 Additionally, as the SQLite source code is public domain, you are free to examine and modify it as you see fit. If SQLite is missing a feature that you absolutely must have, why not add it yourself and give something back to the community?
姝ゅ錛屽洜涓篠QLite鐨勬簮浠g爜鏄紑鏀劇殑錛屼綘鍙互鑷敱鐨勬鏌ュ拰淇敼鍙浣犺涓哄悎閫傘傚鏋淪QLite鐜板湪緙哄皯涓涓綘寰堥渶瑕佷絾鍗磋繕娌℃湁鐨勭壒鎬э紝涓轟粈涔堜笉鑷繁娣誨姞鐒跺悗緇欑ぞ鍖哄洖璧犱竴浜涘憿錛?/font>
SQLite now has extensive support for other programming languages through APIs that use the underlying C/C++ interface to communicate with SQLite database files.
The core interface is implemented as a single library called libsqlite.so on Linux/Unix systems and sqlite.dll on Windows.
Only the SQLite library is required to allow all users to create their own databases, so very little administration is required to add SQL database capability to a shared system.
Support for SQLite in PHP has been available for a while, but since the release of PHP 5, it has been shipped with the standard distribution.
Traditionally, PHP and MySQL have gone hand in hand as the interface and back end for dynamic web sites, but it is expected that many more web hosting providers will offer SQLite as PHP 5 gains popularity. From the host's point of view, it is much simpler to administer than a client/server database as there are no complex permissions to manage and database files will be already counted in the disk quota.
Note
SQLite has proved itself to work very well with low- to medium-traffic web sites. As a very rough guideline, if you are expecting over 100,000 hits per dayand in practice, only a small number of web sites will have this level of trafficyou should consider how much database work is done by the web scripts and think about doing some kind of stress testing before committing to SQLite as your back end.
Perl allows access to SQLite through the Database Interface (DBI) module. This makes it very easy for existing Perl developers to use SQLite within their scripts. The DBI provides an abstraction layer to the Database Driver (DBD), so the same command set is used to access many different types of underlying databases.
The DBD::SQLite driver further allows access to the capabilities of SQLite that the Perl DBI does not allow. Although this does not create a Perl application that can be easily ported to another database back end, it does allow access to the powerful user-defined functions feature.
The Tcl interface for SQLite is shipped as part of the SQLite distribution as a library that is imported into Tcl to activate the extensions.
Using Tcl and Tk together with SQLite, you have a platform that is ideal for rapid development of portable graphical user applications.
SQLite has APIs for many other programming languages, including Java, .NET, Smalltalk, and Ruby. As more languages become supported, they are added to the list at
http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers
.
The downside of using a single file to store databases is that SQLite is not as scalable as many client/server database systems.
The SQLite engine can address database files of up to 2TB in size; however, the restriction on the size of a database is more likely to be enforced by your operating system. In many cases, the size limit on a single file is 2GB.
File locking in SQLite is very coarse-grained. When a write operation takes place, the entire file is locked so that no other process can open it for reading or writing. Larger RDBMSs implement locking at the table or row level so that other processes are able to carry on working unless they are trying to access a specific piece of locked data.
Therefore, if you have a database that is likely to involve massive database files or a high frequency of slow write operations, SQLite may not be suitable and you should consider an RDBMS that is designed and tuned for multiple-user access.
浠嬬粛
SQLite is an embeddable SQL-driven database engine that implements both the database engine and its interface as a C/C++ library. Started in 2000 by D. Richard Hipp, it was written from the ground up and contains absolutely no legacy code, and the SQLite source code has been in the public domain since the first prerelease of version 2.0 in 2001.
SQLite鏄竴涓祵鍏ュ紡鐨凷QL椹卞姩鐨勬暟鎹簱寮曟搸錛屽畠鍙互浣滀負(fù)鏁版嵁搴撳紩鎿庢垨鑰匔/C++搴撶殑鎺ュ彛浣跨敤銆傚畠鐢盌. Richard Hipp鍦?000騫村垱寤猴紝瀹冩槸瀹屽叏閲嶅啓鐨勭粷瀵逛笉鍖呭惈浠諱綍鐨勮佺▼搴忋傝嚜浠?001騫寸殑2.0鐗堟湰SQLite鐨勯鍙戣鐗堝彂甯冧互鏉ユ簮浠g爜灝卞叕寮浜嗐?/font>
Simple to administer
鏄撲簬綆$悊
Simple to operate
鏄撲簬鎿嶄綔
Simple to use in a program
鏄撲簬鍦ㄧ▼搴忎腑浣跨敤
Simple to maintain and customize
鏄撲簬緇存姢鍜屽畾鍒?/font>
The fact that SQLite is small, fast, and reliable arguably its greatest strengthsis, according to Hipp, a happy coincidence. He concentrated on making SQLite simple, and reliability is a byproduct of having fewer things to go wrong. Having simpler code in the database engine makes it much easier to optimize.
鎸塇ipp鎵璇達紝浜嬪疄涓奡QLite寰堝皬錛屽緢蹇拰鍙互淇¤禆鐨勶紝騫朵笖璇佹槑鏈夊崜瓚婄殑寮哄害錛宎 happy coincidence銆備粬鑷村姏浜庝嬌SQLite綆鍗曞寲錛岃鏇村皯鐨勪笢瑗垮嚭閿欑殑鍓駭鍝佸氨鏄彲淇¤禆鎬с傛暟鎹簱寮曟搸浠g爜鐨勭畝鍗曞寲浣垮緱瀹冪殑浼樺寲瀹規(guī)槗鐨勫銆?br />
The acronym SQL is sometimes pronounced sequel, although in common usage it is most often said as three letters. SQLite, however, is pronounced sequel-lite by its creatorin the same way that Microsoft SQL Server is usually pronounced sequel-serverand therefore that is how we have assumed it is said in this book. As we will refer to a SQLite database and an SQL statement, it will help if you are used to hearing them this way as you read on.
涓轟粈涔堜嬌鐢⊿QLite錛?/font>
There are many reasons for choosing SQLite, including
Performance SQLite performs database operations efficiently and is faster than other free databases such as MySQL and PostgreSQL.
鎬ц兘 SQLite鍦ㄦ墽琛屾暟鎹簱鎿嶄綔鐨勬椂鍊欒姣旇濡侻ySQL鍜?/font>
PostgreSQL絳夎嚜鐢辨暟鎹簱楂樻晥鍜屽揩閫熴?/font>
Size SQLite has a small memory footprint and only a single library is required to access databases, making it ideal for embedded database applications.
澶у皬 SQLite鏈夊緢灝忕殑闇瑕佸緢灝戠殑鍐呭瓨錛屽茍涓旇闂暟鎹簱鍙渶瑕佷竴涓崟鐙殑搴撴枃浠訛紝榪欎簺浣垮畠鎴愪負(fù)宓屽叆寮忔暟鎹簱搴旂敤鐨勭悊鎯抽夋嫨銆?/font>
Portability SQLite runs on many platforms and its databases can be ported easily with no client/server setup or ongoing administration required.
鍙Щ妞嶆?/strong> SQLite鍙互鍦ㄥ緢澶氬鉤鍙頒笂榪愯錛屽茍涓斾粬鐨勬暟鎹簱鍙互鍦ㄦ病鏈夊鎴風(fēng)/鏈嶅姟鍣ㄨ緗?鍜岀鐞嗕笉闂存柇鐨勬儏鍐典笅榪涜縐繪銆?/font>
Stability SQLite is ACID-compliant, meeting all four criteria Atomicity, Consistency, Isolation, and Durability.
紼沖畾鎬?/strong> SQLite閬典粠涓嶅彲鍒嗗壊鎬у師鍒欙紝絎﹀悎鎵鏈夌殑鍥涗釜鏍囧噯鍘熷瓙鎬э紝涓鑷存э紝闅旂鎬э紝鍜岃愪箙鎬с?/font>
SQL support SQLite implements a large subset of the ANSI-92 SQL standard, including views, subqueries, and triggers.
SQL聽 SQLite鏀寔ANSI-92 SQL鏍囧噯鐨勪竴涓ぇ鐨勫瓙闆嗗伐鍏鳳紝鍖呮嫭瑙嗗浘錛屽瓙鏌ヨ鍜岃Е鍙戝櫒銆?/font>
Interfaces SQLite has language APIs for C/C++, PHP, Perl, Python, Tcl, and many more beyond those covered in this book.
鎺ュ彛 SQLite鏈?C/C++, PHP, Perl, Python, Tcl鍜屾洿澶氱殑鍦ㄦ湰涔︿箣澶栫殑璇█銆?/font>
Cost SQLite is in the public domain and therefore is free to use for any purpose without cost and can be freely redistributed.
璐圭敤 SQLite 鏄叕寮鐨勶紝鍥犳鍙互浠繪剰鐨勮嚜鐢變嬌鐢ㄥ畠鑰屼笉闇瑕佷粯璐癸紝騫朵笖鍙互鑷敱鐨勯噸鏂板彂甯冦?/font>
]]>
Features and Limitations
It is important to decide whether SQLite or any other database engine for that matteris the right choice for your application before committing to a particular technology.
鍦ㄤ負(fù)浣犵殑搴旂敤紜畾涓涓壒孌婄殑鎶鏈箣鍓嶏紝鍐沖畾閫夋嫨浣跨敤SQLite鎴栬呭叾瀹冪殑浠諱綍鏁版嵁搴撳紩鎿庝綔鏄潪甯擱噸瑕佺殑銆?br />
Speed
The published speed comparison at
http://www.sqlite.org/speed.html
compares SQLite to both MySQL and PostgreSQL. It finds that SQLite can perform up to 20 times faster than PostgreSQL and more than twice as fast as MySQL for common operations.
These tests were performed with default installations of each database, and although it is possible to tune the MySQL and PostgreSQL servers for slightly better performance in a given environment, SQLite does not require any such optimization.
The tests found that SQLite is significantly slower than the other databases only on the operations to create an index and to drop a table. However, slowness in these areas will not affect performance on a production database.
榪欎釜嫻嬭瘯鍙戠幇錛孲QLite浠呬粎鍦ㄦ墽琛屽垱寤虹儲寮曞拰鍒犻櫎琛ㄧ殑鎿嶄綔鏃墮熷害瑕佹瘮鍏朵粬鏁版嵁搴撴參寰楀銆傜劧鑰岋紝榪欎簺鏂歸潰寰椾綆閫熷茍涓嶄細(xì)褰卞搷鍒頒綔涓轟竴涓敓浜ф暟鎹簱銆?br />
Portability
SQLite has no external dependencies. The SQLite library is self-contained, so the only system requirement to run an application with an embedded SQLite database is the SQLite library itself. Because SQLite can be freely distributed, you can always ensure that this is present.
SQLite娌℃湁棰濆鐨勪緷璧栨с係QLite 搴撴槸鑷寔鐨勶紝鍥犳鍦ㄨ繍琛屽祵鍏ュ紡SQLite鏁版嵁搴撶殑鏃跺欙紝浠呬粎闇瑕佺殑鏄疭QLite鐨勫簱鏈韓銆傚洜涓篠QLite鑳藉鑷敱鐨勫彂甯冿紝浣犳繪槸鍙互紜繚榪欐槸鍙鐨勩?br />
Security
瀹夊叏
聽SQLite 鏁版嵁搴撳瓨鍌ㄥ湪鏂囦歡緋葷粺涔嬩笂錛岃闂帶鍒舵槸鐢卞熀浜庢搷浣滅郴緇熶箣涓嬬殑鐨勬枃浠舵潈闄愯瀹氭潵瀹炵幇鐨?/font>銆?/p>
The advantage of this is one of administrative simplicitythere is no need to set up a complex user grants scheme. Any user who has access to read the database file is able to access the database tables and records. Likewise, in a shared environment, users are able to create their own SQLite databases to their file space without any involvement from the system administrators.
The disadvantage comes when you want to control permissions at a more finely grained level. There is no GRANT operation that would allow access to particular tables to one set of users but not others. If users have read access, they are able to read the entire database, and if they have write access, you have to be sure of their competence and trustworthiness with the data!
緙虹偣鏄紝褰撲綘闇瑕佸湪鏇村姞緇嗚嚧綺掑害姘村鉤鐨勬帶鍒舵潈闄愮殑鏃跺欙紝瀹冩病鏈塆RANT鎿嶄綔錛岃繖涓搷浣滃厑璁鎬竴閮ㄥ垎鐢ㄦ埛鍙闂壒瀹氱殑琛ㄨ屽彟涓閮ㄥ垎鐢ㄦ埛涓嶈銆傚綋鐢ㄦ埛鎷ユ湁璁塊棶璁稿彲錛屼粬浠兘澶熻鏁翠釜鏁版嵁搴擄紝濡傛灉浠栦滑鏈夊啓璁稿彲錛屼綘蹇呴』瑕佺‘瀹氫粬浠湪鏁版嵁涓婄殑鐨勬潈闄愬拰淇¤禆搴?/font>銆?br />
SQL Implementation
For example, atomic transactions are available but cannot be nested; simple subqueries are possible but correlated subqueries are not; triggers can fire for each row but not for each statement; views are available but are read-only.
In the vast majority of cases, none of the limitations of SQLite will cause problems when developing your application. For those that you need to work around, the benefits of using a fast, portable embedded database will almost certainly outweigh the cost of the workaround.
鍦ㄥぇ閮ㄥ垎鐨勬儏鍐典笅錛孲QLite鐨勫眬闄愭т笉浼?xì)缁欎綘鐨勫簲鐢ㄥ紑鍙戦犳垚浠諱綍闂銆傚洜姝わ紝浣犻渶瑕佸彉閫氱殑鏂規(guī)硶錛屼嬌鐢ㄤ竴涓揩閫熺殑錛屽彲縐繪鐨勫祵鍏ュ紡鏁版嵁搴撶殑濂藉灝嗘瘮鍙橀氭柟娉曠殑璐圭敤濂界殑澶氥?br />
Customization
Supported APIs
C/C++
PHP
Perl
Tcl
Other Programming Languages
Scalability
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽鎽樿嚜銆奡QLite銆?a class="v1" target="_new">Chris聽Newman钁?/font>
]]>
The primary design goals when SQLite was conceived were that it should be
SQLite鏋勬兂鏃跺欑殑涓昏璁捐鐩爣鏄細(xì)
Note
娉ㄦ剰
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽鎽樿嚜銆奡QLite銆?/font>Chris聽Newman钁?/font>
]]>
聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽聽 鎽樿嚜銆奡QLite銆?a class="v1" target="_new">Chris聽Newman钁?img src ="http://www.shnenglu.com/cc/aggbug/7989.html" width = "1" height = "1" />
Why Use SQLite?
閫夋嫨SQLite鏈夎澶氱悊鐢憋紝鍖呮嫭錛?/font>
]]>