* Last Updated
全体が、部分ごとの合計より大きいことがあるか?
これは私たちが4D v11 SQLの新しいアルゴリズムを作成するときに考えていた問題です。すべてのコマンドが個別に考慮され、ユニットテストを通じて性能の改善を評価する方法を知ってはいますが、パフォーマンスのトータルな性能向上を決定するのは、ユーザの感じ方です。
これを念頭におき、私たちは、絶え間なく変化するリクエストをクライアント/サーバ環境で実行する、可能なかぎり現実的なアプリケーションに対して私たちのテストを走らせるべきと考えました。

4D SQL v11の特定の振舞いを例証するために、私たちは単純なストラクチャからリクエストを行います。このケースはコールセンター管理アプリケーションのサブセットです。
データベースは電話によるコミュニケーションを追跡します、そして異なる統計要求がクライアントマシン上でオペレータによって行われます。
| Exchanges | 1,000 |
| Customers | 10,000 |
| Telephone lines | 100,000 |
| Communications | 1,000,000 |
| Bills | 可変 |
以下はこのタイプの動作の、4つの典型的な処理シーケンスの結果です:

シーケンス 1: 地域ごとの通信数
通信の地理的な概観を得るために、地域ごとのオフィス数を得ます。このため郵便番号を使用します。
例えば、フランスのマリチームアルプスに位置する顧客は郵便番号が06000と06999の間です。クエリは依存フィールドに対して行われ、[communication]テーブルに対する検索を、リンクされたフィールド[customer]codepostalを使用して行います。
4D v11 SQLエンジンの最適化により20%の向上が見られました。
シーケンス 2: 毎月の顧客取引高
シーケンス 3: リアルタイムな取引高
I一般に、使用されないデータを検索するのは役に立ちません。 4D v11 SQLは、コードの実行を予期して、データにアクセスするためにエンジンが必要とする情報を事前にロードし、いかに続く処理の速度を向上させます。
これらの2つの例では、私たちは与えられた日のすべての通信、あるいは顧客の毎月の通信、いずれかについてクエリします。そして"price"フィールドの合計を計算します。
4D v11 SQLの最適化により、この計算は前のバージョンより2-4倍速くなりました。
シーケンス 4 : 通信の一覧
日ごと行われる通信の詳細な一覧を作成したいとします:

これを行うために、上記スキーマの紫のリンクを自動に設定します。
通信ごとに、コマンドRELATE ONEを使用してリレーとしたレコードを選択、ロードします。
クライアント/サーバでは、テーブル [phone_exchange]、[customer]、[line]のレコードはクライアントに転送されます。
4D v11 SQLの最適化により、1つのリクエストにおけるリレートした3つのテーブルのレコードのロードと転送において、ネットワーク経由のリクエストは減少しています。
このテストを行った条件下においては、4D v11 SQLは4D 2004に比べ、8倍速いという結果になりました。