sqlite rowid與主鍵

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.