• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            woaidongmao

            文章均收錄自他人博客,但不喜標題前加-[轉貼],因其丑陋,見諒!~
            隨筆 - 1469, 文章 - 0, 評論 - 661, 引用 - 0
            數據加載中……

            SQLite數據庫掃盲

            今天注意到SQLite 3.6.11(上個月發布的)增加了一個我期待已久的online backup接口,激動之余就順便和大伙兒聊一下SQLite數據庫。本帖權當是SQLite掃盲,如果你對SQLite已經很熟悉,本文就不必再看了。

              ★技術上的優點和特性
              SQLite是一個輕量級、跨平臺的關系型數據庫。既然號稱關系型數據庫,支持SQL92標準中常用的玩意兒(比如視圖、事務、觸發器等)就是理所當然的了,咱今天就不細說了。今天主要聊聊一些有點特色的玩意兒。

              ◇輕量級
              先說它的第一個特色:輕量級。想必SQLite的作者很看重這個特性,連它的Logo都是用的羽毛,來顯擺它的輕飄飄。
              SQLiteC/S模式的數據庫軟件不同,它是進程內的數據庫引擎,因此不存在數據庫的客戶端和服務器。使用SQLite一般只需要帶上它的一個動態庫,就可以享受它的全部功能。而且那個動態庫的尺寸也挺小,以版本3.6.11為例,Windows487KBLinux347KB

              ◇綠色軟件
              SQLite的另外一個特點是綠色:它的核心引擎本身不依賴第三方的軟件,使用它也不需要安裝。所以在部署的時候能夠省去不少麻煩。

              ◇單一文件
              所謂的單一文件,就是數據庫中所有的信息(比如表、視圖、觸發器、等)都包含在一個文件內。這個文件可以copy到其它目錄或其它機器上,也照用不誤。

              ◇跨平臺/可移植性
              如果光支持主流操作系統,那就沒啥好吹噓的了。除了主流操作系統,SQLite還支持了很多冷門的操作系統。我個人比較感興趣的是它對很多嵌入式系統(比如AndroidWindows MobileSymbinPalmVxWorks等)的支持。

              ◇內存數據庫(in-memory database
              這年頭,內存越來越便宜,很多普通PC都開始以GB為單位來衡量內存(服務器就更甭提了)。這時候,SQLite的內存數據庫特性就越發顯得好用。
              SQLiteAPI不區分當前操作的數據庫是在內存還是在文件(對于存儲介質是透明的)。所以如果你覺得磁盤I/O有可能成為瓶頸的話,可以考慮切換為內存方式。切換的時候,操作SQLite的代碼基本不用大改,只要在開始時把文件Load到內存,結束時把內存的數據庫Dump回文件就OK了。在這種情況下,前面提到的“online backup API”就派上用場了,聰明的同學應該明白我為啥這么期待backup功能了吧?

              ★技術上的缺點和不足
              前面光聊了特性和優點,為了避免槍手寫軟文的嫌疑,再來說說SQLite的一些缺點。列位看官將來如果想用它,這些缺點要權衡一下。

              ◇并發訪問的鎖機制
              SQLite在并發(包括多進程和多線程)讀寫方面的性能一直不太理想。數據庫可能會被寫操作獨占,從而導致其它讀寫操作阻塞或出錯。

              ◇
            SQL標準支持不全
              在它的官方網站上,具體列舉了不支持哪些SQL92標準。我個人感覺比較不爽的是不支持外鍵約束。

              ◇網絡文件系統(以下簡稱NFS
              有時候需要訪問其它機器上的SQLite數據庫文件,就會把數據庫文件放置到網絡共享目錄上。這時候你就要小心了。當SQLite文件放置于NFS時,在并發讀寫的情況下可能會出問題(比如數據損壞)。原因據說是由于某些NFS的文件鎖實現上有Bug

              ★編程語言接口
              SQLite支持很多種語言的編程接口。這對于我這種喜歡混用多種編程語言的人來說,是很爽的。下面我大概介紹一下。

              ◇
            C/C++
              由于SQLite本身是C寫的,它自帶的API也是C接口的。所以C/C++用起來最直接了。假如你不喜歡面向過程的C API風格,可以另外找個C++的包裝庫。想重新發明輪子的同學,也可以自己包裝一個。
              ◇
            Java
              如果要用Java訪問SQLite,可以通過SQLiteJDBC驅動,或者通過專門的SQLite包裝庫。我個人建議走JDBC方式,萬一將來要換數據庫,代碼就不用大改。
              ◇
            Python
              pysqlitePython操作SQLite的首選。從Python 2.5開始,它已經被整合到Python的標準庫中。看來Python社區還是蠻喜歡SQLite嘛。
              ◇
            dotNet
              對于喜歡dotNet的同學,可以通過SQLiteADO.NET驅動來訪問。
              ◇
            Ruby
              Ruby可以通過SQLite-Ruby操作SQLite數據庫,不過我沒用過。
              ◇
            Perl
              在CPAN上有DBD::SQLite,不過我也沒用過。

              ★一些非技術的參考因素
              前面講的都是技術層面的話題,如果你考慮在公司的商業軟件項目中使用SQLite。還需要根據如何選擇開源項目里面提到的幾個參考因素,再評估一下。
              ◇授權協議(License
              SQLite使用的是Public Domain協議,這是最爽一種,可以放心大膽地用。
              ◇用戶的普及程度
              最近這幾年,使用SQLite的人越來越多(從Google Trends可以反應出來)。包括一些大公司也開始把它整合到產品中(比如GoogleGearsAppleSafariAdobeAIR)。這說明它的健壯性、穩定性等方面不會有太大問題。
              ◇開發的活躍程度
              如果到SQLiteChange Log上大致了解一下,可以看出最近5年基本上每1-2個月都會有更新。說明開發的活躍度還是非常高的。
              從上述幾個非技術因素來看,SQLite用于商業公司的軟件項目還是非常靠譜的。

             

            posted on 2009-06-20 00:19 肥仔 閱讀(299) 評論(0)  編輯 收藏 引用 所屬分類: 數據庫

            久久经典免费视频| 久久久亚洲欧洲日产国码二区| 久久精品国产免费一区| 国产精品久久久久一区二区三区 | 蜜臀久久99精品久久久久久| 亚洲一区精品伊人久久伊人| 亚洲精品乱码久久久久久自慰| 国产精品一区二区久久不卡| 国产精品xxxx国产喷水亚洲国产精品无码久久一区| 91久久九九无码成人网站| 国产69精品久久久久APP下载| 国产精品久久影院| 欧美久久综合九色综合| 成人免费网站久久久| 久久天天婷婷五月俺也去| 777久久精品一区二区三区无码| 亚洲天堂久久久| 久久久久无码国产精品不卡| 国产aⅴ激情无码久久| 欧美粉嫩小泬久久久久久久| 久久综合综合久久综合| 亚洲精品国产自在久久| 青青青国产精品国产精品久久久久| 久久精品国产亚洲av麻豆蜜芽 | 91麻精品国产91久久久久| 亚洲欧美日韩中文久久 | 久久电影网| 999久久久免费精品国产| 综合人妻久久一区二区精品| 香蕉久久影院| 一97日本道伊人久久综合影院| 国产成人精品久久亚洲| 一本大道久久a久久精品综合| 久久精品国产亚洲av影院| 亚洲人成精品久久久久| 亚洲精品乱码久久久久久久久久久久 | 91超碰碰碰碰久久久久久综合| 国内精品久久久久久99| 中文无码久久精品| 久久人人爽人人爽人人片AV不 | 国产69精品久久久久777|