-2

いくつかのチュートリアルを見つけましたが、それでも疑問が残ります。

2 つのテーブルの典型的な例を見てみましょう。1 つは顧客の詳細用で、もう 1 つは注文の詳細用です。

データベース内のcustomersテーブルには次のものがあります。

  • customer_id主キーとして の自動インクリメント整数
  • 顧客名のテキスト フィールド
  • 連絡先の詳細のテキスト フィールド

ordersテーブルには次 のものがあります。

  • テーブルcustomer_idを参照する外部キーである整数customers
  • アイテム番号の束への参照など、その他のもの
  • order_value注文の現金値を格納する整数

2 つのデータセット コンポーネント、2 つのクエリ、および接続が必要です。

ここまでは順調ですね?それとも、私はすでに何かを逃しましたか?

さて、チュートリアルでは、DB グリッドに対応するデータソースの MasterSource を設定する必要があると書かれています。これは、テーブルordersに対応するデータソースであるcustomersテーブルと、MasterFieldsこの場合は に対応するテーブルを示していますcustomer_id

他に何か?たとえば、テーブルにDetailfields対応するデータソースのクエリの を に設定する必要がありますか?customerscustomer_id

プロパティまたはパラメータ化されたクエリを使用する必要がありますか?

この時点で、従来のチュートリアルに従って、DB グリッドをスクロールして、customersDB グリッドに表示されている現在の顧客のすべての注文を確認できますorderscustomersユーザーがDB グリッドをクリックすると、Close(); する必要があります。次に Open(); 対応する DB グリッドを更新するordersクエリ。

ただし、これらのチュートリアルは常に、変更されることのない既存のコンテンツを含む静的データベースを前提としているようです。

私が別の質問をしたとき、私がコマンドを使用していた例を挙げたINSERT INTO orders...ところ、それは悪いことだと言われ ました。

  • OrdersQuery.Append();
  • OrdersQuery.FieldByName('customer_id') := [何らかの値]';
  • OrdersQuery.FieldByName('item_numbers') := [何らかの値]';
  • OrdersQuery.FieldByName('order_value') := [何らかの値]';
  • OrdersQuery.Post();

あれは正しいですか?

コマンドはデータを入れて、クエリはそれを取り出すだけのように見えるので、私は尋ねますが、コマンドはデータソースのクエリを介してDBグリッドにリンクしていないことがわかります。

これは選択の問題ですか、それともクエリを使用する必要がありますか?

もしそうなら、クエリでSUM、MIN<AVG、MAXなどの単純なSQL関数でさえ使用できず、それらをコードに移動する必要があるようです。

UPDATEクエリを使用する必要がある場合、SQLを実装するにはどうすればよいDROPですか?

最後に、Master/Detail/Det​​ail の関係を作成できますか?

顧客のすべての注文の合計と平均を示す 3 番目の DB グリッドが必要だとします。ordersユーザーが別の顧客を選択するたびに更新されるテーブル (ただし、SUM と AVG は使用できません)からデータを取得し、マスター/詳細/詳細の関係を提供します。それを 2 つのマスター/ディテール関係として設定しただけですか? IE、DB グリッド、データソース、総注文数と平均注文数のクエリorderscustomerscustomer_id?

助けと明確化を前もって感謝します。この質問が将来他の人の参考になることを願っています(自由に編集してください)。

4

1 に答える 1

2

TLDR:SQLの世界では、マスター/詳細は古語法です。

「マスターディテール」と言う人がいると、うさぎの穴まで下がることはありません。あなたの質問はあなたがしたいことを示唆しています。私が役立つと思ういくつかのことを共有したいと思いますが、誰もがあなたの質問に完全に答えることができるとは思いません。

  1. 一部の人々の目的のために、任意の2つのデータセットのマスター詳細の最小限の実装は、マスターテーブルで現在選択されている行が変更されたときに発生するイベントハンドラーにすぎません。次に、この行を使用して詳細テーブルデータセットの行をフィルタリングし、マスター行の主キーに一致する行のみが表示されるようにします。これは、DelphiのVCLのほとんどのTTableに似たオブジェクトで適切に構成すれば、自動的に行われますが、マスター/詳細構成を明示的にサポートしないデータセットでも、書き込みを希望する場合は、このように機能させることができます。いくつかのイベントハンドラー、およびフィルターデータ。

  2. 私の以前の雇用主の1人で、ある人がマスターディテールコントローラーコンポーネントを発明しました。これは、カミアックとして知られるDelphi用のADOコンポーネントのほとんど知られていないバリアントと一緒に、BDE-TTableに精通しているだけの人々が持ついくつかのプロパティを持っていました。マスターディテールの時代のコンセプトは予想していなかったでしょう。これは非常に巧妙な作業であり、次の機能がありました。

    • マスター行をディスクに保存する場合に限り、ADOレコードセットを作成してメモリに保持し、バッチとして一連の詳細行を一度に書き込むことができます。
    • これらのマスターと詳細の関係をほぼ任意の深さにネストできるため、マスター、詳細、およびサブ詳細のレコードを作成できます。質問のその部分に答えるために、UPDATESにはバッチ更新が使用されました。更新を処理するには、独自のORMまたはRecordsetレイヤーをロールするか、事前に構築されたキャッシング/レコードセットレイヤーを使用する必要があります。ADOから、DelphiのさまざまなORMのようなコンポーネント、さらにはクライアントデータセットやデータポンプを備えたブリーフケースモデルに関連するものまで、多くのオプションがあります。
    • データを変更してメモリ内のステージング領域に投稿し、すべてのマスター行と詳細行を一度にフラッシュするか、それらを破棄することができます。これにより、ほぼオブジェクトリレーショナルレベルの永続性管理が可能になりました。

ロール・ユア・オウン・ORMアプローチが上にあるように見えるのと同じくらい素敵ですが、それは暗い面がないわけではありませんでした。システムの奇妙なバグにより、私はそのようなアプローチを二度と使いたくなくなりました。誇張したくはありませんが、マスターディテールのうさぎの穴を行き過ぎてしまうようなことがあるのではないかと謙虚に提案できますか?そこに行かないでください。または、そうする場合は、実際にミニORMを構築していることを認識し、単体テストと統合テストのかなり堅実なセットを含む作業を行う準備をしてください。それでも、かなり奇妙なコーナーケースを発見する可能性があり、いくつかの本当に邪悪なバグがあなたの美しいORM/MasterDetailのものに潜んでいることに気付くかもしれないことに注意してください。

挿入物に関する限り、それはもちろん、あなたがビルダーであるかユーザーであるかによって異なります。VCLにあるテーブルクラスの上に構築することに満足していて、SQLで手を汚したくない人は、SQLを恐れていなければ、あなたのアプローチは間違っていると思うでしょう。ただし、その人は自動割り当てされたID主キーをどのように処理するのでしょうか。個人レコードをテーブルに格納し、すぐにその個人の新しく割り当てられたID(整数)をフェッチする必要があります。次に、その整数の主キーを使用して、詳細行をマスター行に関連付けます。したがって、詳細行は、マスター行のID整数を外部キーとして参照します。これは、SQLデータベースが適切に構築されており、参照整合性の制約があるためです。これらすべてを事前に考えており、これを何度も繰り返したくないので、最終的にはここからオブジェクトリレーショナルマッピングフレームワークを構築することになります。あなたの多くの質問がどれほど多くの可能な答え、何百または何百万もの可能なアプローチにつながる答えを持っているかをあなたが見ることができることを願っています、そして誰も正しいものはありません。私はたまたまORMを信じていません。このクレイジーな電車を降りるのに安全な場所は、乗る前だと思います。私はSQLを手作業でコーディングし、ビジネスオブジェクトを手作業でコーディングしています。また、凝ったマスターディテールやORMのものは使用していません。ただし、好きなように選択することもできます。数百または数百万の可能なアプローチにつながる答えであり、正しいものはありません。私はたまたまORMを信じていません。このクレイジーな電車を降りるのに安全な場所は、乗る前だと思います。私はSQLを手作業でコーディングし、ビジネスオブジェクトを手作業でコーディングしています。また、凝ったマスターディテールやORMのものは使用していません。ただし、好きなように選択することもできます。数百または数百万の可能なアプローチにつながる答えであり、正しいものはありません。私はたまたまORMを信じていません。このクレイジーな電車を降りるのに安全な場所は、乗る前だと思います。私はSQLを手作業でコーディングし、ビジネスオブジェクトを手作業でコーディングしています。また、凝ったマスターディテールやORMのものは使用していません。ただし、好きなように選択することもできます。

BDE / dBase / flat-fileの時代に「マスター詳細」として実装していたものを、マスター行のクエリとして実装し、詳細行の2番目のクエリとして実装し、マスター行が変更されたら、詳細行のクエリでありMasterSource、TTableオブジェクトのまたは関連するMaster/Detailプロパティをまったく使用していません。

于 2013-03-13T02:21:54.100 に答える