web-dev-qa-db-ja.com

SQLiteテーブルの主キーとしてテキストを使用するのは悪いことですか？

SQLiteデータベースの主キーとしてテキストを使用するのは悪いことですか？パフォーマンス上の理由から悪いと聞きましたが、本当ですか？そのような場合、ROWIDは実際の主キーとして使用されますか？

androiddatabasesqliteprimary-keyrowid
26
mpellegr

SQLiteデータベースの主キーとしてテキストを使用するのは悪いことですか？パフォーマンス上の理由から悪いと聞きましたが、本当ですか？

正確性の観点から、TEXT PRIMARY KEYは大丈夫です。

パフォーマンスの観点から、INTEGERキーを優先します。ただし、パフォーマンスの問題と同様に、自分で測定して、データとユースケースに大きな違いがあるかどうかを確認します。

そのような場合、ROWIDは実際の主キーとして使用されますか？

ROWIDでエイリアスされるのはINTEGER PRIMARY KEYのみです。他の種類の主キーはサポートせず、WITHOUT ROWIDが指定されていない限り、暗黙の整数ROWIDが存在します。 参考 。

32
laalto

現実の世界では、文字列を主キーとして使用することには、UUIDについて語る場合に多くの利点があります。エンティティ「パスポート」を作成時に正確に作成できると、非同期コードや分散システム（あるいは、より複雑なモバイルクライアント/サーバーアーキテクチャについて話している場合）を大幅に簡略化できます。

パフォーマンスについては、ベンチマークを実行して10000の主キールックアップを実行しても、測定可能な違いは見つかりませんでした。実際、データベースインデックスは、インデックス付き検索を実行するときに文字列を格納したり比較したりしません。

14
Segabond

タイプPRIMARY KEYのフィールドは、値の比較を意味します。数値の比較は、テキストの比較より簡単です。

その理由は、64ビット数値比較のための特定のアセンブリ命令があるためです。これは常に、理論的にはサイズが無制限のテキストを比較するよりもはるかに高速です。

数を比較する例：

CMP DX, 00  ; Compare the DX value with zero
JE  L7      ; If yes, then jump to label L7
.
.
L7: ...

CMP組み立て手順の詳細については、こちらをご覧ください： https://www.tutorialspoint.com/Assembly_programming/Assembly_conditions.htm

これを知ることで、数値のパフォーマンスが常に向上することを知ることができます（少なくとも今日の計算では）。

0
Sergio Cabral

はい、TEXTを使用すると、Android.database.sqlite.SQLiteConstraintException：UNIQUE制約が失敗します：TableName.ColumnName（コード1555）

SQLiteは、この挿入が成功した場合、最後に挿入された行の行IDを挿入して返すセッションを持っています。それ以外の場合は-1を返します。

returnは_IDにマップされます。これが、テーブルのBaseColumnsのインターフェースを強制する理由です。

その奇妙なことに、挿入呼び出しはブール値などではなく、ROWIDを返す必要があります

テキストプライマリキー機能がsqliteにあったらいいのに

0
Bipin