System.Data.SQLite との比較

2005 年、Robert Simpson は、ADO.NET 2.0 の SQLite プロバイダーである System.Data.SQLite を作成しました。 2010年、SQLiteチームはプロジェクトのメンテナンスと開発を引き継いだ。 Mono チームが 2007 年に Mono.Data.Sqlite としてコードをフォークしていることも注目に値します。 System.Data.SQLite は長い歴史を持ち、Visual Studio ツールを備えた安定したフル機能の ADO.NET プロバイダーへと進化しました。 新しいリリースでは、.NET Framework のすべてのバージョンと互換性のあるアセンブリがバージョン 2.0 および .NET Compact Framework 3.5 に引き続き出荷されます。

.NET Core の最初のバージョン (2016 年にリリース) は、.NET の単一の軽量で最新のクロスプラットフォーム実装でした。 より新しい代替手段を備えた古い API と API は意図的に削除されました。 ADO.NET DataSet API (DataTable や DataAdapter を含む) は含まれていませんでした。

Entity Framework チームは、System.Data.SQLite コードベースにやや慣れていました。 EF チームの元メンバーである Brice Lambson は、以前、SQLite チームが Entity Framework バージョン 5 と 6 のサポートを追加するのを支援していました。 また、Brice は、.NET Core が計画されているのと同じ頃に、SQLite ADO.NET プロバイダーの独自の実装を試していました。 長い議論の後、Entity Framework チームは、Brice のプロトタイプに基づいて Microsoft.Data.Sqlite を作成することを決定しました。 これにより、.NET Core の目標に合った新しい軽量で最新の実装を作成できます。

よりモダンな意味の例として、System.Data.SQLite と Microsoft.Data.Sqlite の両方で ユーザー定義関数を作成するコードを次に示します。

// System.Data.SQLite
connection.BindFunction(
    new SQLiteFunctionAttribute("ceiling", 1, FunctionType.Scalar),
    (Func<object[], object>)((object[] args) => Math.Ceiling((double)((object[])args[1])[0])),
    null);

// Microsoft.Data.Sqlite
connection.CreateFunction(
    "ceiling",
    (double arg) => Math.Ceiling(arg));

2017 年、.NET Core 2.0 では戦略が変更されました。 .NET Core の成功には、.NET Framework との互換性が不可欠であると判断されました。 削除された API の多く (DataSet API を含む) が追加されました。 他の多くの場合と同様に、このブロックが解除された System.Data.SQLite を使用して、.NET Core に移植することもできます。 ただし、Microsoft.Data.Sqlite の本来の目標は軽量で最新のものであることに変わりません。 Microsoft.Data.Sqlite によって実装されていない api の詳細については、ADO.NET 制限 ADO.NET 参照してください。

Microsoft.Data.Sqlite に新機能が追加されると、System.Data.SQLite の設計が考慮されます。 可能であれば、2 つの間の変化を最小限に抑えて、それらの間の遷移を容易にしようとします。

データ型

Microsoft.Data.Sqlite と System.Data.SQLite の最大の違いは、データ型の処理方法です。 データ型で説明されているように、Microsoft.Data.Sqlite は SQLite の根本的な風変わりを隠そうとしません。これにより、任意の文字列を列型として指定でき、INTEGER、REAL、TEXT、BLOB の 4 つのプリミティブ型のみが含まれます。

System.Data.SQLite は、.NET 型に直接マッピングする列型に追加のセマンティクスを適用します。 これにより、このプロバイダーはより厳密に型指定されている印象を与えますが、改善が必要な点もあります。 たとえば、SELECT ステートメントで式の列型を指定するために、新しい SQL ステートメント (TYPES) を導入する必要がありました。

接続文字列

Microsoft.Data.Sqlite の 接続文字列 キーワードが大幅に少なくなります。 次の表は、代わりに使用できる代替手段を示しています。

キーワード	オルターナティブ
キャッシュ サイズ	PRAGMA cache_size = <pages> を送信する
FailIfMissing	Mode=ReadWrite を使用する
FullUri	Data Source キーワードを使用する
履歴モード	PRAGMA journal_mode = <mode> を送信する
従来の形式	PRAGMA legacy_file_format = 1 を送信する
最大ページ数	PRAGMA max_page_count = <pages> を送信する
ページ サイズ	PRAGMA page_size = <bytes> を送信する
[読み取り専用]	Mode=ReadOnly を使用する
同期	PRAGMA synchronous = <mode> を送信する
うり	Data Source キーワードを使用する
UseUTF16Encoding	PRAGMA encoding = 'UTF-16' を送信する

認可

Microsoft.Data.Sqlite には、SQLite の承認コールバックを公開する API はありません。 この機能に関するフィードバックを提供するには、問題 #13835 を使用します。

データ変更通知

Microsoft.Data.Sqlite には、SQLite のデータ変更通知を公開する API はありません。 この機能に関するフィードバックを提供するには、問題 #13827 を使用します。

仮想テーブル モジュール

Microsoft.Data.Sqlite には、仮想テーブル モジュールを作成するための API がありません。 この機能に関するフィードバックを提供するには、問題 #13823 を使用します。

関連項目

• データ型
• 接続文字列
• 暗号化
• ADO.NET の制限事項
• Dapper の制限事項