在用sqlite設計表時，每個表都有一個自己的整形id值作為主鍵，其實可以不指定這麼一個id值，sqlite内部本來就會為每個表加上一個 rowid，這個rowid可以當成一個隐含的字段使用，但是由sqlite引擎來維護的，在3.0以前rowid是32位的整數，3.0以後是 64位的整數，為什麼不直接使用這個内部的rowid作為每個表的id主鍵呢。
以下是我的界面設計圖：
以下DDL代碼：
用指定INTEGER PRIMARY KEY AUTOINCREMENT 和不指定自增長字段用rowid有什麼差別:
使用自增長字段為主鍵有不少問題，比如維護或是在大型分布應用中主鍵沖突的解決等。在一些大型分布應用中主鍵一般選用guid，這可以有效的避免主鍵沖突，減少對主鍵維護的工程。當然，對于中小型的應用，自增長字段的好處更多一些，簡單、快速。
Sqlite中，一個自增長字段定義為INTEGER PRIMARY KEY AUTOINCREMENT，那麼在插入一個新資料時，隻需要将這個字段的值指定為NULL，即可由引擎自動設定其值，引擎會設定為最大的rowid+1。當然，也可以設定為非NULL的數字來自己指定這個值，但這樣就必須自己小心，不要引起沖突。當這個rowid的值大于所能表達的最大值 9223372036854775807 （3.0及以後版本的rowid最大值）後，rowid的新值會這個最大數之前随機找一個沒被使用了的值。是以在rowid達到最大值前，rowid的值是嚴格單調增加的。 INTEGER PRIMARY KEY AUTOINCREMENT 自增長字段的算法與rowid稍微有些不同。 第一，在達到最大值後，rowid會找已被删除的字段對應的rowid作為新值，而自增長字段則會丢出一個SQLITE_FULL的錯誤。 第二，自增長字段在增加新值時，是找一個從沒被使用過的rowid作為新值，而rowid則是找最大已存在的rowid+1。這裡對應用的影響會比較大，尤其是一些對id值有依賴的元記錄，隻适合使用自增長字段而不能用rowid。
第三，使用自增長字段，引擎會自動産生一個sqlite_sequence表，用于記錄每個表的自增長字段的已使用的最大值，使用者可以看到，并可以用使用 Update、Delete和Insert操作，但不建議這麼使用，這會讓引擎混亂。如果使用rowid，也會有這麼一個内部表，使用者可以維護rowid 值，但看不到。 這麼看來，如果直接使用rowid來代替自增加字段，根據兩者的細微的差别，需要注意是否與自己的應用沖突，如果沒有沖突，那麼用rowid會更快一點。
SQLite中建立自增字段，一個聲明為 INTEGER PRIMARY KEY 的字段将自動增加。
從 SQLite 的 2.3.4 版本開始，如果你将一個表中的一個字段聲明為 INTEGER PRIMARY KEY，那麼無論你何時向該表的該字段插入一個 NULL 值，這個 NULL 值将自動被更換為比表中該字段所有行的最大值大 1 的整數；如果表為空，那麼将被更換為 1。
一個新的API函數 sqlite3_last_insert_rowid() 傳回最近的插入操作的整形鍵.
注意這個整型鍵始終比之前插入表中的最後一個鍵大1。
新鍵相對于表中的已有鍵來說是唯一的，但它可能與之前從表中删除的鍵值重疊。
要始終得到在整個表中唯一的鍵，在INTEGER PRIMARY KEY的聲明之前加關鍵詞AUTOINCREMENT.這樣被選的鍵将總是比表中已存在的最大鍵大1。若可能的最大鍵已存在于表中，INSERT操作将失敗并傳回一個SQLITE_FULL錯誤碼.