關于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的問題總結就先介紹到這里，我們還會在以后的文章中接著介紹，感興趣的朋友可以繼續關注。
【編輯推薦】
