關於sqlite遇到問題時的一點思考

本文主要介紹sqlite資料庫遇到的一些問題以及解決的思路，接下來我們一一介紹。

rowid和Integer主鍵及自增屬性

大多數情況下，sqlite3的表都有一個rowid(也叫oid,_rowid_),這是一個64位的整數，並作為sqlite儲存結構B樹的主鍵。因此使用rowid查詢會比以其他設定的主鍵查詢，速度會非常快。

在做插入操作的時候，對於rowid的值通常情況下不要去指定，讓系統自己去決定該去何值。因為sqlite會通過SQLITE_SEQUENCE來追蹤表的rowid取值情況。而且sqlite定義了rowid的取值演算法：在未超出rowid的範圍內，待插入記錄的rowid總是表中存在過的的rowid最大值+1。比如依次插入5條記錄，此時最後一條記錄的rowid是5，如果把這條記錄刪除再插入新記錄，此時新紀錄的rowid是6。而當rowid達到所能表達的最大值時，這時如果有新紀錄要插入，系統就會隨機從之前的沒有使用過的正整數中隨機取一個作為rowid(就是之前刪除過的)。若沒有未使用的正整數並且你沒有在插入的時候制定rowid為某一個負數的話，系統就會拋出SQLITE_FULL的錯誤。

如果在建立表的時候設定了主鍵，並且設定主鍵的那列是integer(不是int,short integer等等)，並且主鍵沒有設定降序時，這時的主鍵是rowid的別名，換言之,主鍵和rowid沒有區別。如果我們再設定主鍵autoincrement屬性時。和rowid又有什麼區別呢?區別只是在於此時主鍵的取值是一個未使用過的rowid值，而這個rowid值系統會保證其是單調增長的,通常情況下就是表中存在過的rowid最大值+1。這裡所說的通常情況下是因為有這樣一種情況：當插入操作由於資料表條件約束而失敗的時候，本來要賦值的rowid，有可能不會在下次插入操作中使用，此時主鍵的取值就是表中存在過的rowid最大值+2。

因此對於使用者id是整數的表，是單獨設主鍵去維護還是直接使用rowid作為主鍵，就取決於各自的商務邏輯關係了。在這種情況下,通常不使用rowid的主鍵特性。

Union All

今天遇到個問題, boss對app有了新的要求,具體到業務上就是：

假設有兩張表：

create table A (username varchar(50), created datetime);   create table B (nickname varchar(50), userID integer, added datetime); 

表A和表B之間沒有任何關係,唯一有聯絡的就是有一列屬性都是datetime。而boss就需要將A和B的所有值取出並按時間排序。

乍一看不知道咋解決，因為兩張表剛好沒有關係啊.後來才意識到可以用union，比如：

select Null as col1, username as col2,created as col3 from A union all  select nickname as col1, userid as col2,added as col3 from B   order by col3; 

然後根據某一列值是否為空白來產生不同的對象。

思考：

1.遇到這個問題後,首先想到的是join，但表又是沒有關係的，所以陷入了死胡同，跳出這個思維，從sql本身出發，問題解決。

2.從軟體開發的角度，對於已經進行了一半的開發，如果有新的需求，對於已有的軟體架構，資料庫結構都會是一個挑戰。但這樣的變化往往是不可避免，尤其是在小公司，用scrum開發的環境下。遇到這樣的問題只能希望架構師依靠自己的檢驗，設計出易於擴充的架構。

取出某一段資料

sqlite取出某一段資料是用limit，比如要取出第6-20條記錄，只需：

select * from TableName limit 5,15. 

關於sqlite的問題總結就先介紹到這裡，我們還會在以後的文章中接著介紹，感興趣的朋友可以繼續關注。