問題タブ [junction-table]

定義によると、ジャンクション テーブル(ブリッジ テーブル/リンク テーブル) は、次のように使用すると、多対多の関係に使用されます。

しかし、1 人のユーザーが多くの注文に関連付けられているこの例のように、1 対多の関係にも同じように簡単に使用できませんでした:

(私はデータベースについてよく理解していないので、誤解があれば訂正してください。)

作成者が結合テーブルに主キーを置くのは良くないと言ったスクリーンキャストを見ていましたが、その理由は説明していませんでした。

この例の結合テーブルには、Rails移行で定義された2つの列があり、作成者は各列にインデックスを追加しましたが、主キーは追加しませんでした。

この例で主キーを使用するのはなぜ良くないのですか？

編集：Cletusに述べたように、結合テーブルの場合でも、主キーとしての自動番号フィールドの潜在的な有用性を理解できます。ただし、上記の例では、作成者は「createtable」ステートメントで構文「：id=>false」を使用して自動番号フィールドを作成することを明示的に回避しています。通常、Railsは、このような移行で作成されたテーブルに自動番号IDフィールドを自動的に追加し、これが主キーになります。しかし、この結合テーブルについては、作成者は特にそれを防ぎました。なぜ彼がこのアプローチに従うことにしたのかわかりませんでした。

対応するカテゴリテーブルと投稿テーブルを参照する列を持つ結合テーブル（上記のとおり）があります。カテゴリ_posts結合テーブルの複合キーcategory_id、post_idに一意性制約を適用したかったのです。しかし、Railsはこれをサポートしていません（私は信じています）。

category_idとpost_idの同じ組み合わせを持つデータ内の重複行の可能性を回避するために、Railsに複合キーがない場合の最善の回避策は何ですか？

ここでの私の仮定は次のとおりです。

1. デフォルトの自動番号列（id：integer）は、この状況でデータを保護するために何もしません。
2. ActiveScaffoldは解決策を提供するかもしれませんが、特によりエレガントな答えがある場合は、この単一の機能のためだけにそれをプロジェクトに含めるのがやり過ぎかどうかはわかりません。

LINQ クエリは正しく機能しますが、生成される SQL は複雑で非効率的であるため、LINQ クエリを最適化しようとしています...

基本的に、必要な製品 (reqdProdId) を注文し、クレジット カード番号に登録されている (CustomerDisplay オブジェクトとして) 顧客を選択しようとしています (外部キー CustId を持つ RegisteredCustomer テーブルの行として保存されます)。

概要として、Customer には Name を持つ対応する Person があります。PersonID は Customer テーブルの外部キーです。生成された SQL を見ると、Person テーブルからすべての列が選択されていることがわかります。参考までに、DisplayName は Customer.FirstName と LastName を使用する拡張メソッドです。Person の列を制限する方法はありますか?

2 番目に、必要な ProductID を持つ他のすべての CustomerIds を選択するために、Any 句を削除 (およびサブクエリを使用) したいと考えています。これは、(当然ながら) Exists 句を生成するためです。ご存じかもしれませんが、LINQ にはジャンクション テーブルに関する既知の問題があるため、cust.CustomerProducts.Products だけを実行することはできません。必要な ProductID を持つジャンクション テーブル内のすべての顧客を選択するにはどうすればよいですか?

ヘルプ/アドバイスをいただければ幸いです。

ID（主キー、自動インクリメント）列とコンテンツ（テキスト）列を持つメッセージテーブルがあります。
ユーザー名（主キー、テキスト）とハッシュの列を持つユーザーテーブルがあります。
メッセージは1人の送信者（ユーザー）から多くの受信者（ユーザー）に送信され、受信者（ユーザー）は多くのメッセージを持つことができます。
MessageID（MessagesテーブルのID列を参照）とRecipient（Usersテーブルのusername列を参照）の2つの列を持つMessages_Recipientsテーブルを作成しました。このテーブルは、受信者とメッセージの間の多対多の関係を表します。

だから、私が持っている質問はこれです。新しいメッセージのIDは、データベースに保存された後に作成されます。しかし、この新しいMessageIDを取得するために、追加したばかりのMessageRowへの参照を保持するにはどうすればよいですか？
もちろん、データベースで最後に追加された行をいつでも検索できますが、マルチスレッド環境では別の行が返される可能性がありますか？

編集：私はSQLiteについて理解しているので、を使用できますSELECT last_insert_rowid()。しかし、ADO.Netからこのステートメントを呼び出すにはどうすればよいですか？

私の永続性コード（messagesとmessagesRecipientsはDataTablesです）：

なぜこれを理解できないのかわかりません。基本的に、多対多の関係を持つ 2 つのテーブルがあるため、その間にジャンクション テーブルがあります。

たとえば、次のデータベース スキーマを考えてみましょう。

そのため、多くのレストランでは多くの料理を提供できます。

私が構築しようとしているクエリは、郊外に存在するすべての料理を返します。SQL の例は次のとおりです。

これは私には理にかなっているようです。

Zend_Db を使用してこれを実装するにはどうすればよいですか?

それで、昨日、同じ考えに基づいた 2 つの質問をしました。A- が正規化されておらず、B- が私の無知のせいで混乱したデータベースの再編成です。一日の大半を自分の考えを整理し、読み上げ、いくつかのテストに取り組みました。今日、DB がどのように見えるべきか、どのように動作するべきかについて、より良いアイデアが得られたと思いますが、適切な SQL DB の設計と正規化プロセスの核となる考え方を理解していることを確認したかったのです。

もともと、ファイルに関するデータ（URL、アップロード日、アップロードした人のユーザーIDなど）を保持する「ファイル」と呼ばれる1つのテーブルと、そのファイルを使用する可能性のある学年レベルを表す「成績」と呼ばれる列がありました為に。(参考: これらのファイルは学校の授業計画です)正規化に関するルール #1 に違反していることに気付きました。「成績」を「1,2」、「2,6」、または「3,5,6」のように保存していました。 」を 1 列に。これは、3 年生のみのレッスンまたは 5 年生のみのレッスンを見たい場合に、そのデータを解析しようとすると大きな頭痛の種になりました。

私に提案され、後で明らかになったのは、3 つのテーブルがあるということでした。

files (ファイルに関するデータ、URL など) grades (利用可能な学年レベルの表。おそらく 1 から 6 まで) files_grades (ジャンクション テーブル)

意味あり、。やる前に自分のやっていることを理解していることを確認したいだけです。ユーザー A がファイル xyz をアップロードし、2 年生と 3 年生に適していると判断したとします。

そのファイルに関するデータ (kb サイズ、url、説明、名前、プライマリ キー files_id) を含む "files" テーブルに 1 つのレコードを書き込みます。ID 345 を取得するとしましょう。

評定オプションの数が限られているため、評定は ID と同等になる可能性があります (つまり、Grade 1 は grades_id 1、Grade 2 は grades_id 2)。

次に、「files_grade」ジャンクション テーブルに 2 つのレコードを書き込みます。

files_grade_id、files_id、および grades_id ie

1,345,2

1,345,3

files_id 345 が適している 2 つのグレードを表します。次に、魔法の SELECT および JOIN ワンドを振って、必要なデータを取得します。

これは理にかなっていますか？繰り返しになりますが、リレーショナル多対多データベースの適切な構造を誤解していますか?

問題 2 : レッスンには複数の「グレード」を含めることができます。問題ありません。問題は解決しました (願わくば!)。しかし、理論的には、小学校、中学校、高校など、複数の「学校」を持つこともできます。ファイル エントリに中、高のグレード 1、2 がある場合はどうすればよいですか? これは、「ファイルごとに 1 つの学校、ユーザー!」と言うだけで簡単に解決できますが、私はこれを捨てたいと思っています。

Productテーブル、Orderテーブル、および（ジャンクションテーブル）ProductOrderがあるとします。

ProductOrderには、ProductIDとOrderIDがあります。
ほとんどのシステムでは、これらのテーブルにはIDと呼ばれる自動番号列もあります。

主キー（およびそのためにクラスター化されたキー）を配置するためのベストプラクティスは何ですか？

• IDフィールドの主キーを保持し、外部キーペア（ProductIDとOrderID）の非クラスター化インデックスを作成する必要があります

• または、外部キーペアの主キー（ProductIDとOrderID）を配置し、ID列に非クラスター化インデックスを配置する必要があります（必要な場合でも）

• または...（あなたの一人による賢い発言:)）

このような設計で、ジャンクションテーブルにレコードを追加したり、レコードを削除したりする機能を作成したいと思います。

ケースは、従業員を編集し、彼らが受けることができる試験を選択するときからです。左側のリストボックスには、（とにかく）資格のない試験があり、右側のリストボックスには資格のある試験があります。

テーブルは次のようなものです。

はEmpID常にExamID認識されますが、左側のリストボックスから選択されます。右側のリストボックスのレコードを削除するには、おそらくEmpIDとの両方が必要です。ExamID

それぞれのボックスに入れたら、すぐに削除/挿入する必要はありません（フォームが閉じるまで待つことができます）。

Accessでこれを達成するための良い/標準的な方法はありますか？

データベースアプリケーションで、ページをサイトに添付しようとすると、次のエラーが発生します。

ジャンクションテーブルを使用して、ページを複数のサイトに追加できるようにするつもりです。

以下は、問題の3つのテーブル（T-SQL）のスキーマです。アドバイスをいただければ幸いです。