SQLiteを直接操作する必要があるのはなぜですか？

経験豊富なiOS開発者なら、すぐにSQLiteを直接（または直接ではなく、FmDbを使用しますが、これは直接とほぼ同じです）を使用していると非難するでしょう。彼はあなたがCoreDataを使用する必要があると言うでしょう、なぜなら UndoやRedoなど、多くのnishtyakを自動的に実行します。そして、その中に美しいスケッチを描くことができ、それを顧客に見せることが楽しくなります。そして、アンドロイドでは、例えば、OrmLiteがあります。

同意しますが、それまでは、データベースが、たとえば、それぞれ500,000エントリの10以上のテーブルを超えるまでです。 52個のテーブルがあり、特に100万個以上のファットテーブルがある場合はどうでしょうか。また、データベースは3番目の形式でサーバーと同期する必要があります。顧客が重要であることに加えて、同期は1時間または5時間続きますか？このようなボリュームのタスクに遭遇した場合は、カットしてください！ビッグデータを使用するプロジェクトから免除されているのは、たとえそのようなモバイルプロジェクトが少なくても、だれも出会っていない場合です。

クエリ演算子の順序

実際、データベースの操作を教えられると、ほとんどの場合、最高のエンタープライズソリューションでの操作を教えられます。例えば、私はOracleの研究所で、MS SQLの誰かに教えられました。しかし、SQLiteは何倍も単純です。たとえば、これは、公式の SQLiteのWebサイトから取られたエピグラフから記事に続きます。

かなり偶然、私はそれに気づいた

SELECT * FROM tablename WHERE col1 LIKE '%string%' AND col2 = 123456

動作が3〜4倍遅い

SELECT * FROM tablename WHERE col2 = 123456 AND col1 LIKE '%string%'

たとえば、300,000レコードのテーブルに。演算子を入れ替えただけで、結果はどう変わったのでしょう！

データベースに関する教科書では、ほとんどの場合、それらはそのような機能に焦点を合わせていません。そして、彼らはそれを正しく行います-すべてのエンタープライズソリューションにはクエリオプティマイザーがあります。たとえば、MS SQL Server 2008 Web Editionでは、同じデータと同じクエリで違いはありません。

しかし、SQLiteには1つあります。これは覚えておく必要があります。 SQLiteの世界では、より単純な操作は常に、より複雑な操作の左側に移動する必要があります。

SQLiteデータベースにもインデックスを付けることができます。

SQLiteを、ストアドプロシージャ、セマフォ、およびユーザーのないデータベースであるfopenの代替として考えると、通常のデータベースと同様に、インデックスをサポートしていることを忘れます。それらについてあまりにも多くのことが書かれているので、構文上の機能に焦点を合わせるべきではありません。データベースのサイズが50,000行を超えるとすぐにインデックスを作成する必要があることを覚えておいてください。複雑なクエリを使用する場合-前。

私は自分自身に小さな発言だけを許可します-インデックス作成は、分析に基づいて、基本的なクエリを作成した後に行うのが最適です。データベースの設計時に、開発者がまだアプリケーションのビジネスロジック全体を暗記していない場合、どのフィールドが最も頻繁に検索/選択されるかを間違える可能性があります。ただし、目の前にSQLクエリがあるため、適切なインデックスを作成する価値はありません。

複数のテーブルで頻繁にサンプリングする場合は、データをキャッシュするのが理にかなっています

プロジェクトの1つでは、アプリケーションの開始時に毎回、ユーザーが作業したい車を選択するように要求する必要がありました。マシンの完全な説明をコンパイルするには、いくつかの表を参照する必要がありました。

製造年
メーカー
モデル
パッケージバンドル
機械を選択する際に顧客が見せたい技術的特性。たとえば、MPG（1ガロンあたりのマイル数、1リットルあたりのキロメートルに相当）。

5つのテーブルでクエリを実行し、車のリストを作成すると、ピッカーごとにiPhoneの応答が6〜8秒に低下しました。 2つの方法があります-最初の開始（同期中）で、可能なすべてのデータを使用してプレゼンテーションを作成するか、より便利な場合はデータオブジェクトを直接ハードディスクに保存します。また、ユーザーが遅延について知っており、待機する準備ができている便利な瞬間に一度。

構成テーブルのいくつかのフィールドを、たとえばマシンごとにビューに含める必要がある場合は、オブジェクトを保存する方が便利です。データベースでは、これにより行の重複が避けられません（複数の構成パラメーターの多くの行に1つを接続した場合、車両IDおよびその他のパラメーターで複数の同一の行を作成する必要があります）。オブジェクトでは、すべてのデータが1つのコピーに格納されます。

SQLite-シングルスレッドデータベース

最適化に直接関係するわけではありませんが、これも忘れないでください。 2つのスレッドのSQLiteデータベースを同時に使用すると、必然的にクラッシュが発生します。 2つの出力があります。

@synchronizedディレクティブを使用して呼び出しを同期します。これは、アーキテクチャを変更するには遅すぎる場合です（私が持っていたように）。
タスクが設計段階で配置される場合、NSOperationQueueに基づいてクエリマネージャーを起動します。エラーに対して自動的に保証し、自動的に行われることは多くの場合エラーなしで行われます。

一般に、UIスレッドが待機インジケータをスクロールする以外に何もしない場合でも、セカンダリスレッドからデータベースにアクセスする方が常に優れています。デリゲートメソッドを記述し、ビジネスロジックを非同期化する時間は、肯定的なユーザーエクスペリエンスを実現する以上のものです。

おわりに

上に挙げたものはすべて特別なケースに過ぎません。 1.5日または総プロジェクト時間の10％で推定できる汎用的な最適化タスクはありません。これは必要に応じて実行する必要があります。最適な最適化パスを選択するのに常に助けとなった主なルールは、 サンプリングに費やされる時間が、特別な場合を除き、データベースサイズの増加に伴って増加しないことです。 100個のレコードと10万個のレコードの両方でほぼ同じままである必要があります。

そしてもう1つのルール、上司のお気に入りのフレーズ-最適化を必要としないものは最適化しないでください。多くの場合、ユーザーがコードを1ミリ秒実行するか100実行するかを気にしません。また、プロジェクトを1日延期したか、期限内に納品したかは顧客にとって重要です。

iOS用SQLiteを使用した作業の最適化