1s 8.3 は完全な接続を要求します。 クエリでの結合

19.06.2023

結合は、データベースに対して実行される最も一般的な操作の 1 つです。 結合は、あるテーブルの行を別のテーブルの行に一致させるために使用されます。 一致はフィールドの 1 つの値 (キーと呼びます) に基づいて行われます。

基本的に、接続は 1 つのサンプル内のさまざまなソースから情報を取得するために使用されます。 言い換えれば、ソースは物理的な意味が異なっていても接続されます。

1C:Enterprises クエリ エンジンによって処理されるテーブル結合には、内部結合、左外部結合の 4 種類があります。 右外部、完全外部 (または、より単純に、内部、左、右、完全)。

内部結合

[INTERNAL] JOIN は、両方のソース テーブル (データ ソース) から、指定された条件を満たすレコードの組み合わせのみがクエリ結果に含まれる必要があることを意味します。 残りのレコードは結果に含まれません。キーワード INTERNAL は省略できます。これにより、クエリ テキストが明確になり、読みやすくなります。

最も単純なタイプの接続は内部接続です。 この場合、クエリは単に一致するキー値を持つ行のペアを検索します ( この例では以降のすべてのフィールドと同様に、「取引相手」フィールドがキー フィールドとして使用されます)。

左(右)接続

LEFT [OUTER] JOIN は、指定された条件を満たす両方のソース テーブルのレコードの組み合わせがクエリ結果に含まれる必要があることを意味します。 ただし、内部結合とは異なり、クエリ結果には、条件に一致する 2 番目のソースのレコードが見つからなかった最初のソース (JOIN という単語の左側に示されている) のレコードも含まれている必要があります。 したがって、クエリ結果には最初のソースからのすべてのレコードが含まれます。 指定された条件が満たされる場合、それらは 2 番目のソースのレコードとマージされます。 2 番目のソースから条件に一致するレコードが見つからなかったクエリ結果行には、このソースからのレコードに基づいて生成されたフィールドに NULL が含まれます。

ソースが完全に一致しない場合、状況はさらに複雑になります。 「つまり、一方のテーブルには特定のキー値を持つレコードがありますが、もう一方のテーブルにはそのようなレコードはありません。 この図は、エントリが取引先テーブルにはあるが、売上テーブルには存在しない場合の状況を示しています。 これは、取引先のディレクトリにはそれが登録されているにもかかわらず、特定の取引先が当社から何も購入しなかったことを意味します (たとえば、ある人が支払いのために請求書を書いてくれるように頼まれたが、購入することに気が変わったなど、非常に現実的な状況です) )。 この場合、欠落しているレコードの代わりに値 Null が選択範囲に表示されます。

ソーステーブル:

完全な接続

RIGHT [OUTER] JOIN は、クエリ結果には、指定された条件を満たす両方のソース テーブルのレコードの組み合わせが含まれている必要があることを意味します。 さらに、クエリ結果には、最初のソースから対応するレコードが見つからなかった 2 番目のソース (CONNECTION という単語の右側に示されている) からのレコードも含まれる必要があります。したがって、クエリ結果には 2 番目のソースからのすべてのレコードが含まれます。 指定された条件が満たされる場合、それらは最初のソースのレコードとマージされます。 最初のソースから条件に一致するレコードが見つからなかったクエリ結果行には、このソースからのレコードに基づいて生成されたフィールドに NULL が含まれます。

完了 外部結合、名前から明らかなように、これは左 (または右) 接続をさらに発展させたものです。 完全結合を構成するときは、この状況を考慮することが重要です。このタイプの結合では、クエリには両方のテーブルのすべてのレコードが含まれます。 つまり、左右のテーブルの両方からキー 0 の値を取得する必要があります。 注意してください: 両方のテーブルからである必要があります。 解決策の 1 つはこれです。このための追加フィールドを作成し、そこで Null をチェックします。 いずれかのテーブルのキーが Null の場合は、別のテーブルからその値を取得する必要があります。

完全結合は他のタイプの結合よりも多少複雑であるため、例を少し変更してみましょう。 ここで、売上の詳細なリストだけでなく、既存のすべての取引先のリストを取得する必要があります。

ソーステーブル:

調達
取引相手
イワノフ 4000
アンドレーエフ 3500
販売
取引相手
イワノフ 5000
ペトロフ 7500
シドロフ 15000

元のテーブルのすべてのフィールドを含む、完全結合後のテーブル:

現在の取引先
取引相手の購入 購入金額 取引先販売 金額売上
イワノフ 4000 イワノフ 5000
ヌル ヌル ペトロフ 7500
ヌル ヌル シドロフ 15000
アンドレーエフ 3500 ヌル ヌル

テーブルの最終的なビュー。取引相手が 1 つのフィールドに要約されています。

現在の取引先
取引相手 購入金額 金額売上
イワノフ 4000 5000
ペトロフ 7500
シドロフ 15000
アンドレーエフ 3500

以下は、対応するリクエストの変形です。 当社は取引相手に関するデータをドキュメントだけでなくサブクエリからも取得していることに注意してください。 それらでは、各取引先がサンプル内で 1 回だけ表示されるように、取引先ごとにグループ化を実行します。 そしてもちろん、Null のことも忘れないでください。

SELECT ISNULL(Receipt.Counterparty.Expense.Counterparty) AS Counterparty、ISNULL(Receipt.Amount, 0) AS AmountPurchases、ECTБNULL(Pacxod.Amount, 0) AS AmountSales FROM (SELECT Receipt.Counterparty AS Counterparty、AMOUNT(Receipt.Amount) AS 金額 FROM Document.Receipt AS Receipt GROUP BY Receipt.Counterparty) AS Receipt FULL CONNECTION (SELECT Expense.Counterparty AS Counterparty, AMOUNT(Expense.Amount) AS Amount FROM Document.Expense AS Expense GROUP BY Expenditure.Counterparty) AS Expense BY Receipt .Counterparty = Expense.Counterparty

クエリ言語は、開発者にとって 1C 8.3 の基本的なメカニズムの 1 つです。 クエリを使用すると、データベースに保存されているデータをすばやく取得できます。 その構文は SQL に非常に似ていますが、いくつかの違いがあります。

SQL に対する 1C 8.3 (8.2) クエリ言語の主な利点は次のとおりです。

  • 参照フィールドの逆参照 (オブジェクトの詳細への 1 つ以上のポイントを参照)。
  • 結果の操作は非常に便利です。
  • 仮想テーブルを作成する機能。
  • リクエストは英語とロシア語の両方で書くことができます。
  • デッドロックを回避するためにデータをブロックする機能。

1C のクエリ言語の欠点:

  • SQL とは異なり、1C のクエリではデータの変更は許可されません。
  • ストアド プロシージャの欠如。
  • 文字列を数値に変換することは不可能です。

1C クエリ言語の基本構造に関するミニチュートリアルを見てみましょう。

1C のクエリではデータの受信のみが許可されるため、クエリはすべて「SELECT」という単語で始まる必要があります。 このコマンドの後に、データを取得する必要があるフィールドが示されます。 「*」を指定すると、使用可能なすべてのフィールドが選択されます。 データが選択される場所 (ドキュメント、レジスタ、ディレクトリなど) は、「FROM」という単語の後に示されます。

以下で説明する例では、命名法全体の名前が「Nomenclature」ディレクトリから選択されます。 「HOW」という単語の後には、テーブルとフィールドの別名 (名前) が示されます。

選ぶ
命名法。 AS 命名法名。
から
Directory.命名法 AS の命名法

「SELECT」コマンドの横に指定できるのは、 キーワード:

  • 様々な。 クエリは、少なくとも 1 つのフィールドが異なる行のみ (重複を含まない) を選択します。
  • 最初のn、 どこ n– 選択する必要がある結果の先頭からの行数。 ほとんどの場合、この構造は並べ替え (ORDER BY) と組み合わせて使用​​されます。 たとえば、日付が新しいドキュメントを一定数選択する必要がある場合です。
  • 許可された。 この設計により、現在のユーザーが使用できるレコードのみをデータベースから選択できます。 このキーワードの使用に基づいて、ユーザーはアクセス権のないレコードをクエリしようとするとエラー メッセージを受け取ります。

これらのキーワードは、一緒に使用することも、個別に使用することもできます。

変化する

この提案は、相互の競合を防ぐためにデータをブロックします。 ロックされたデータは、トランザクションが終了するまで別の接続から読み取られません。 この句では、ロックする必要がある特定のテーブルを指定できます。 そうしないと全員がブロックされます。 この設計は自動ロック モードにのみ関係します。

ほとんどの場合、「FOR CHANGE」句は残高を受け取るときに使用されます。 結局のところ、いつ 同時作業プログラム内の複数のユーザーが、1 人が残高を受け取り、もう 1 人が残高を変更できます。 この場合、結果として得られる剰余は正しくなくなります。 この提案でデータをブロックすると、最初の従業員が正しい残高を受け取り、それに対して必要なすべての操作を実行するまで、2 番目の従業員は待機することになります。

選ぶ
従業員相互決済。
相互決済額 相互決済残高
から
従業員との相互決済の記録 AS 相互決済。
変化する

どこ

アップロードされたデータに何らかの選択を加えるにはデザインが必要です。 レジスタからデータを取得する場合には、仮想テーブルのパラメータに選択条件を指定する方が合理的です。 「WHERE」を使用すると、最初にすべてのレコードが取得され、その後でのみ選択が適用されるため、クエリの速度が大幅に低下します。

以下は、特定のポジションの連絡担当者を取得するリクエストの例です。 選択パラメータの形式は &ParameterName (パラメータ名は任意です) です。

セレクション(ケース)

この設計では、リクエストの本文で条件を直接指定できます。

以下の例では、ドキュメントが投稿されるかどうかに応じて、「AdditionalField」にテキストが含まれます。

選ぶ
入場料T&U.Link、
選択
入場時T&U.実施
その後、「書類は通過しました!」
ELSE 「文書は投稿されませんでした...」
追加フィールドとして終了
から
商品およびサービスの受領方法に関する文書。

参加する

結合は、特定の関係条件に基づいて 2 つのテーブルをリンクします。

左右の接続

LEFT 結合の本質は、最初に指定されたテーブル全体が取得され、接続条件に従って 2 番目のテーブルがそのテーブルにリンクされることです。 2 番目のテーブルに最初のテーブルに対応するレコードがない場合は、その値として NULL が代入されます。 簡単に言うと、メイン テーブルは最初に指定されたテーブルであり、2 番目のテーブル (存在する場合) のデータはすでにそのデータに置き換えられています。

たとえば、品目は「商品およびサービスの受領」文書から取得し、価格は情報レジスタ「商品価格」から取得する必要があります。 で この場合、ポジションの価格が見つからない場合は、代わりに NULL を代入します。 価格の有無に関係なく、ドキュメントのすべてのアイテムが選択されます。

選ぶ
領収書とU.命名法、
価格.価格
から
商品およびサービスの受領書。商品の受領書と仕様。
内部結合 RegisterInformation.PricesNomenclature.SliceLast AS 価格
ソフトウェアの受領書とU.命名法 = 価格.命名法

右ではすべてが正反対です。

完全接続

このタイプの接続は、結果として最初のテーブルと 2 番目のテーブルの両方のすべてのレコードが返されるという点で前の接続とは異なります。 指定されたリンク条件に基づいて最初または 2 番目のテーブルにレコードが見つからない場合は、代わりに NULL が返されます。

前の例で完全接続を使用する場合、「商品およびサービスの受領」文書からのすべての品目アイテムと、「品目価格」レジスタからのすべての最新価格が選択されます。 最初と 2 番目のテーブルの両方で見つからないレコードの値は NULL になります。

内部結合

INNER JOIN と FULL JOIN の違いは、少なくとも 1 つのテーブルでレコードが見つからない場合、クエリではそのレコードがまったく表示されないことです。 その結果、前の例で「FULL」を「INTERNAL」に置き換えると、情報レジスタ「品目価格」にレコードが存在する文書「商品およびサービスの受領」の品目のみが選択されます。

グループ化

1C クエリのグループ化では、特定の共通特性 (グループ化フィールド) に従ってテーブル行 (グループ化フィールド) を折りたたむことができます。 グループ化フィールドは、集計関数を使用してのみ表示できます。

次のクエリの結果は、製品タイプとその最大価格のリストになります。

選ぶ
,
MAX(価格.価格) AS 価格
から

グループ化
価格.命名法.命名法の種類

結果

グループ化とは異なり、合計を使用する場合は、すべてのレコードが表示され、合計行がレコードに追加されます。 グループ化では、一般化されたレコードのみが表示されます。

結果は、テーブル全体 (キーワード「GENERAL」を使用)、複数のフィールド、または次のフィールドについて合計できます。 階層構造(キーワード「階層」、「階層のみ」)。 結果を要約する場合、集計関数を使用する必要はありません。

グループ化を使用した上記の例と同様の例を見てみましょう。 この場合、クエリ結果はグループ化されたフィールドだけでなく、詳細なレコードも返します。

選ぶ
価格.命名法.命名法の種類 AS 命名法の種類、
価格.価格としての価格
から
情報の登録。最新の AS 価格のスナップショット。
結果
最大(価格)
による
種類の名称

持っている

この演算子は WHERE 演算子に似ていますが、集計関数にのみ使用されます。 この演算子で使用されるフィールドを除く残りのフィールドはグループ化する必要があります。 WHERE 演算子は集計関数には適用できません。

以下の例では、アイテムの最大価格が 1000 を超える場合に、アイテム タイプごとにグループ化されて選択されます。

選ぶ

MAX(価格.価格) AS 価格
から
情報の登録。最新の AS 価格のスナップショット。
グループ化
価格.命名法.命名法の種類
持っている
MAXIMUM(価格.価格) > 1000

注文方法

ORDER BY 演算子は、クエリの結果を並べ替えます。 レコードが一貫した順序で表示されるようにするために、AUTO ORDER が使用されます。 プリミティブ型は通常の規則に従ってソートされます。 参照型は GUID によって並べ替えられます。

名前でソートされた従業員のリストを取得する例:

選ぶ
従業員.名前 AS 名
から
Directory.Employees HOW 従業員
注文方法
名前
自動注文

その他の 1C クエリ言語構造

  • 組み合わせる– 2 つのクエリの結果を 1 つにまとめます。
  • すべてを組み合わせる– COMBINE に似ていますが、同一の行をグループ化することはありません。
  • 空のテーブル– 空のネストされたテーブルを指定するためにクエリを結合するときに使用されることがあります。
  • 場所– 複雑な 1C クエリを最適化するために一時テーブルを作成します。 このようなリクエストはバッチリクエストと呼ばれます。

クエリ言語の機能

  • 部分文字列指定された位置から指定された文字数まで文字列を切り詰めます。
  • 年...2 年目数値型の選択された値を取得できます。 入力パラメータは日付です。
  • 期間の開始と期間の終了日付を扱うときに使用されます。 期間のタイプ (DAY、MONTH、YEAR など) は追加パラメータとして示されます。
  • 追加日日付 (SECOND、MINUTE、DAY など) から特定のタイプの指定時刻を加算または減算できます。
  • 差分日付 2 つの日付の差を決定し、出力値のタイプ (DAY、YEAR、MONTH など) を示します。
  • ISNULL欠損値を指定された式で置き換えます。
  • 表現と表現リンク指定されたフィールドの文字列表現を取得します。 それぞれ任意の値に適用する場合と参考値のみに適用する場合があります。
  • タイプ、タイプ値入力パラメータのタイプを決定するために使用されます。
  • リンク属性値タイプの論理比較演算子です。
  • 急行値を目的の型に変換するために使用されます。
  • 日時数値(年、月、日、時、分、秒)から日付値を取得します。
  • 意味 1C リクエストでは、ディレクトリ、列挙、特性の種類のプランなど、事前定義された値を示すために使用されます。 使用例:「 ここで、法的個人 = 値(列挙.法的個人.個人)«.

クエリビルダー

1C でクエリを作成するには、クエリ デザイナーという非常に便利な組み込みメカニズムがあります。 次の主要なタブが含まれています。

  • 「テーブルとフィールド」 - 選択する必要があるフィールドとそのソースが含まれています。
  • 「接続」 - CONNECTION 構造の条件を説明します。
  • 「グループ化」 - グループ化構造とそれらに基づく合計フィールドの説明が含まれます。
  • 「条件」 - リクエスト内のデータを選択します。
  • "追加" - 追加オプション「SELECT」コマンドのキーワードなどのリクエスト
  • 「結合/エイリアス」 - テーブルを結合する可能性が示され、エイリアスが指定されます (「HOW」構造)。
  • 「順序」はクエリの結果を並べ替える役割を果たします。
  • 「合計」 - 「グループ化」タブに似ていますが、「合計」構成に使用されます。

リクエストのテキスト自体は、左下隅にある「リクエスト」ボタンをクリックすると表示されます。 このフォームでは、手動で修正するか、コピーすることができます。


リクエストコンソール

のために クイックビューエンタープライズ モードでのクエリ結果、または複雑なクエリのデバッグが使用されます。 これにはリクエストのテキストが含まれ、パラメータを設定し、結果を表示します。

クエリ コンソールは、ITS ディスクまたは 経由でダウンロードできます。

複数のテーブルのデータを同時に確認したいとき。 複数のテーブルを 1 つにまとめると、テーブルとテーブル間の関係を接続するという概念が生まれます。 接続には 4 つのタイプがあります。

  • 左;
  • 右、
  • 内部;
  • 完了。

抽象的な例を使用して、各タイプを見ていきます。 2 つのテーブルがあり、最初のテーブルにはアイテムに関する説明情報が保存され、2 番目のテーブルにはその残高に関する情報が保存されます。

これらのテーブルからテーブルを取得するには、どのフィールドをどのような条件とタイプで接続するかを明示的に指定する必要があります。 今、それはより明らかになるでしょう。

左接続

左結合を使用して、結果として接続条件を満たす左側のテーブルのすべてのレコードと右側のテーブルのレコードを表示するようにシステムに指示します。 等しい条件を使用して製品フィールドでテーブルを接続すると、次のようなテーブルが得られます。

リクエスト.テキスト =
"選ぶ
| 命名法.製品、
| Nomenclature.Color AS ColorNomenclature、
| Remains.Color AS ColorRemains、
| 残高.数量
|から

";

剰余テーブルには椅子に一致するものがなかったため、フィールドには NULL 値が入力されました。この値は ISNULL 関数で処理する必要があります。「1C 8 クエリ言語関数」を参照してください。

左結合はループ内のループのように機能します。左のテーブルから最初のレコードを取得し、右のテーブルのすべてのレコードを実行して、接続条件が満たされていることを確認します。 次に、2 番目のレコードが左側のテーブルから取得され、以下同様に続きます。 右側のテーブルのいくつかのレコードが接続条件を突然満たした場合、結果のテーブルにいくつかの行が追加されます (ご覧のとおり、結果のテーブルは情報を提供せず、データは反映されません)。本当の本質であるため、これらのテーブルを Product と Color の 2 つのフィールドで接続することをお勧めします。今回は NULL のみを処理します。

リクエスト.テキスト =
"選ぶ
| 命名法.製品、
| 命名法.色、
| ISNULL(残りの数量, 0) AS 数量
|から
| 命名法 AS の命名法
| LEFT JOIN 剰余 AS 剰余
| ソフトウェア命名法.Product = 残り.Product

正しい接続

右の接続は基本的に左の接続と変わりません。 テーブルを交換すると、右結合は左結合に変わります。さらに、コンストラクターを使用すると、システム自体がすべての右結合を左結合に変換します。

内部結合

内部結合を使用して、結果として右側のテーブルと左側のテーブルの両方から接続条件を満たすレコードのみを表示するようにシステムに指示します。 したがって、結果として得られるレコードの数は、結合に参加している最も短いテーブルのレコードの数以下になります。 テーブルの Product フィールドと Color フィールドに内部結合を適用してみましょう。

リクエスト.テキスト =
"選ぶ
| 命名法.製品、
| 命名法.色、
| 残りの数量 AS 数量
|から
| 命名法 AS の命名法
| INNER JOIN の剰余 AS の剰余
| ソフトウェア命名法.Product = 残り.Product
| そして、Nomenclature.Color = Remaining.Color";

完全な接続

完全結合の結果、両方のテーブルのすべてのレコードが得られ、接続条件を満たすレコードは接続され、接続条件を満たさないレコードもクエリ結果に残りますが、一部の NULL フィールドが含まれます。 左右の接続がひとつになったようなコンプリートです。

このトピックに関しては多くの問題が考えられます。そのうちの 1 つを解決してみましょう。 私たちの組織は、「Zarya」と「Rassvet」という 2 つの家具工場のディーラーです。 各工場のコストを含む品揃えは、別のテーブルに保存されます。 単一の価格表を作成し、最低価格の製品を含める必要があります。

すべてのフィールドを選択して完全結合を適用しましょう。製品ごとに接続します。

リクエスト.テキスト =
"選ぶ
| 命名法Zarya.Product AS ProductZarya、
| 命名法Zarya.Price AS PriceZarya、
| 命名法 Rassvet 製品 AS 製品 Rassvet、
| 命名法Rassvet.Price AS PriceRassvet
|から

これは正確には必要なものではありません。product フィールドを 1 つに結合して NULL を処理しましょう。

リクエスト.テキスト =
"選ぶ
//ISNULL 構造についてはクエリ言語関数のセクションで説明しました
//価格が定義されていない場合は初期化します
//なぜ 1000000 なのかは以下の説明を参照してください
| ISNULL(NomenclatureZarya.Price, 1000000) AS PriceZarya,
| ISNULL(NomenclatureRassvet.Price, 1000000) AS PriceRassvet
|から
| 命名法Zarya AS 命名法Zarya
| フルコネクションの命名法Dawn AS の命名法Dawn
| ソフトウェア命名法Zarya.Product = NomenclatureDawn.Product";

あとは最低価格を選択するだけです。 最終的なリクエスト テキストは次のようになります。

リクエスト.テキスト =
"選ぶ
| ISNULL(NomenclatureZarya.Product, NomenclatureDawn.Product) AS 製品、
| 選択
| WHEN THERE ISNULL(NomenclatureZarya.Price, 1000000) > ISNULL(NomenclatureRassvet.Price, 1000000)
| THEN ISNULL(命名法Rassvet.Price, 1000000)
| ELSE ISNULL(命名法Zarya.Price, 1000000)
| 価格どおりに終了
|から
| 命名法Zarya AS 命名法Zarya
| フルコネクションの命名法Dawn AS の命名法Dawn
| ソフトウェア命名法Zarya.Product = NomenclatureDawn.Product";

価格が定義されていない (NULL) 場合は、何らかの値で初期化する必要があります。そうしないと、多いか少ないかの比較操作がエラーで失敗します。 問題の条件に応じて最低価格を選択するため、比較操作で「損失」が生じるように、非現実的な金額で価格を初期化します。

← 1C クエリ言語の機能 8 | 1C 8 クエリで結合 →

では、詳しく見てみましょう 化合物テーブル。

1C8 クエリ言語にはいくつかのタイプの接続が存在する可能性があることを思い出してください。 左接続, 右結合, 内部結合, 完全接続。 それぞれを詳しく見てみましょう。

  • 左接続

    左結合の場合、1 つのテーブルのデータが完全に選択され、右で結合されたテーブルからは、これらのテーブルが結合される 1 つ以上の条件が満たされるレコードのみが選択されます。 もちろん、この文から理解できることはほとんどないので、例を見てみましょう。
    「製品」というテーブルがあります。

    次のクエリを使用して、1C クエリ コンソールでこのテーブルを作成しましょう。

    商品コードとして「001」、名前として「リンゴ」を選択 すべてを結合 「002」、「オレンジ」を選択 すべてを結合 選択「003」、「みかん」

    次のような「国」テーブルもあります。

    製品コード
    001 ロシア
    002 トゥルキエ
    003 モロッコ

    また、次のクエリを使用して構築します。

    製品コードとして「001」を選択、国として「ロシア」を選択 すべてを選択 「002」、「トルコ」を選択 すべてを選択 「003」、「モロッコ」を選択

    次に、左結合を使用してこれら 2 つのテーブルを接続し、製品コード、名前、および国を含むテーブルを取得しましょう。 これを行うには、テーブルを一時テーブルに配置し、バッチ クエリで左結合を実行します。

    もちろんフィールドごとにレコードをリンクします 製品コード

    SELECT "001" AS 製品コード、"Apples" AS Name PLACE VT_Product COMBINE ALL SELECT "002"、"オレンジ" COMBINE ALL SELECT "003"、"ミカン" ; //////////////////////////////////////////////// /////////////////////////// 製品コードとして「001」、国として「ロシア」を選択 PLACE VT_ Country COMBINE ALL SELECT "002" , "トルコ" COMBINE ALL SELECT "003"、"モロッコ" ; //////////////////////////////////////////////// /////////////////////////// VT_Product.製品コード、VT_Product.Name、VT_country.country FROM VT_Product AS VT_Product LEFT CONNECTION VT_country AS VT_country ソフトウェアを選択しますVT_Product.製品コード = VT_国.製品コード

    このコードをクエリ コンソールにコピーして実行すると、次の結果が得られます。

    ここでは、左側のテーブルの各エントリが右側のテーブルの 1 つのエントリに対応する理想的な状況を調べました。 もう少し複雑にしてみましょう。

    製品にさらに価格が設定されているとします。 また、日付によって変更される場合があります。

    製品コード 日付 価格
    001 01.01.2016 120
    001 01.02.2016 150
    002 01.01.2016 200
    004 01.01.2016 350

    ここでは、製品コード 001 (Apples) について、価格テーブルに 2 つのエントリがあることがわかります。 みかんには値段がありません。 また、価格には商品表にない商品コード004が含まれております。 コードフィールドに接続条件を指定して製品と価格の左結合を実行し、何が得られるかを見てみましょう。

    SELECT "001" AS 製品コード、"Apples" AS Name PLACE VT_Product COMBINE ALL SELECT "002"、"オレンジ" COMBINE ALL SELECT "003"、"ミカン" ; //////////////////////////////////////////////// /////////////////////////// 製品コード「001」、日付「01/01/2016」、価格 120 を選択 PLACE TU_Priceすべて結合 選択 "001"、"02/01/2016"、150 結合すべて選択 "002"、"01/01/2016"、200 結合すべて選択 "004"、"01/01/2016"、350 ; //////////////////////////////////////////////// /////////////////////////// VT_Product.Product コード、VT_Product.Name、VT_Price.Price、VT_Price.Date FROM VT_Product AS VT_Product 左接続を選択します。 VT_Price AS VT_Price BY VT_Product.製品コード = VT_Price.製品コード

    リクエストを実行すると、次の図が表示されます。

    結果を分析してみましょう。 すべてのレコードは「Products」テーブルから選択されています。 それが私たちのメインです。 みかんの場合、価格は NULL です。 コード 003 のエントリは価格表にありません。 そして、価格表のコード 004 のエントリ (これは私たちにとって補助的なものです) は無視されました。 製品表には一致するものはありません。 ご覧のとおり、product テーブルにはコード 001 のレコードが 1 つしかないにもかかわらず、リンゴに関するレコードが 2 つあります。 ここに、テーブル結合の危険性の一部が存在します。

    そして、初心者も経験豊富なプログラマーもこの傾向に陥ります。 メインテーブルにレコードが 1 つあり、結合テーブルの複数のレコードが結合条件を満たす場合、最終テーブルのレコード数は補助テーブルのレコード数と等しくなります。 私たちの場合、リンゴを含むレコードが複製されました。 この点は、クエリを作成するときに考慮し、テスト中にチェックする必要があります。

  • 右結合

    左のものとほとんど変わりません。 最終テーブルには、右側のテーブルのすべてのレコードと、左側のテーブルの結合条件が満たされるレコードのみが含まれます。 実際には、正しい結合は実際には使用されないため、個別に考慮しません。 1C クエリ デザイナーの正しい結合に関連する小さな面白い瞬間もあります。 デザイナーでクエリを作成するときに右結合を使用しようとすると、[OK] をクリックした後に右結合が自動的に左結合に変換されます。

  • 内部結合

    内部結合の場合、結合条件が満たされる左右のテーブルのレコードのみが最終テーブルに表示されます。 最後のクエリで次の行を置き換えると、

    左接続 VT_Price AS VT_Price

    内部接続 VT_Price AS VT_Price

    そして最終的には次のようになります:

    つまり、みかんのエントリが消えてしまったのです。 価格表には一致するものはありませんでした。

  • 完全接続

    完全結合の場合、結果のテーブルには両方のテーブルのすべてのレコードが含まれます。
    この例では、接続文字列を使用する場合、

    フル接続 BT_Price AS BT_Price

    次の結果が得られます

    実際には、完全な接続が使用されることはほとんどありませんが、場合によっては必要になります。

1C8 リクエストの処理を始めたばかりの場合は、「接続」タブで両方を確認することをお勧めします。