問題タブ [database-relations]

別のテーブルを参照する一意のIDのみを実際に必要とするデータベーステーブルがいくつかあります。

Holidayなどのこれらのテーブルは、実際には顧客に関する情報を保持するためにのみ存在します。したがって、休日のIDを保持するために別のフィールドを指定する必要がありますか？すなわち

または、この場合、CustomerIDをテーブルの主キーとして設定するだけで大​​丈夫ですか？

よろしく、ジェームズ。

別のレコードを参照する必要があるが、同じテーブルのテーブルがあります。次に例を示します。

私はこれをするのが悪いと感じています。私のもう 1 つのアイデアは、関係を格納した別のテーブルを用意することでした。

このような些細なことを複雑にしすぎているかもしれませんが、この特定のシナリオに最適なアプローチについていくつかのアイデアを得たいと思いますか?

ありがとう。

ご覧のとおり、同じテーブルに 2 つの外部フィールドがあります。しかし、Kohana ORM のデフォルトでは、存在しない priority_id というフィールドが検索されます。

これら2つのフィールドがそのテーブルへの外部キーであることをKohana ORMに知らせる方法はありますか?

関連テーブルに追加のフィールドをいくつか用意して、多対多の関係で追加のデータを保持したいと考えています。たとえば、「メンバー」、「モデレーター」、「管理者」など、ユーザーがネットワークでどのような役割を持っているかを追跡したいと思います。また、ユーザーがいつネットワークに参加したかも追跡したいと思います。今、私が探しているのは、Doctrine を使用してこれらの余分なフィールドを取得する効率的な方法です。非常に単純化されていますが、典型的な DQL クエリは次のようになります。

1. したがって、Members リレーションから User を取得した場合、NetworkMembers リレーションに「バックトラック」して追加のフィールドを取得する方法はありますか?

2. そうでない場合、これを効率的に実行できるようにスキーマを再配置するにはどうすればよいですか?

   (つまり、メンバーが私が開始したネットワークを見つけて、役割と member_since フィールドをフェッチする必要があるすべてのネットワークを反復処理したくありません)。

私の問題のコード図:

以下のスキーマ:

シナリオ

3 つのデータベース テーブルがあります。1 つは画像用で、残りの 2 つは人物と場所用です。一人一人が多くのイメージを持つことができ、それぞれの場所が多くのイメージを持つことができるので、私は場所とイメージだけでなく、人とイメージも ONE TO MANY の関係にしたいと考えています。

質問

外部キーは主キーと同じ名前にする必要がありますか? または、「PKTableID」など、画像テーブルの外部キーを一般的なものと呼ぶことは可能ですか。このようにして、必要な画像テーブルは 1 つだけです。

大変助かります。

よろしく、

編集：

イメージ テーブルを 1 つだけにしたい理由は、各イメージが他の 1 つのテーブルのみを参照するためです。これと同様に、ここでは 2 つのテーブルの例を使用しました。実際に使用するデータベースには 20 個のテーブルがあるため、20 個の 1 対多の関係に対して SINGLE IMAGE TABLE を使用できるかどうかを知りたかったのです。 ?

「Product」というクラスと「Image」というクラスがあるプロジェクトに取り組んでいます。各商品には「前面」画像と「背面」画像の2種類の画像があるため、2つのフィールドを定義しました。1つはimage_front_idと呼ばれ、もう1つはimage_back_idと呼ばれます。

BaseProduct :: setUp（）メソッドで、正面画像の関係を次のように定義しました。

さて、明らかに、クラス「Image」に別の「hasOne」を定義すると、ローカルフィールド名が「image_back_id」になりますが、これは正しく機能しません。だから私の質問は、同じクラスに対して複数の「1対1」の関係をどのように定義できるかということです。しばらく探していましたが、見つからないようです。

クラスの自己関係を実装する方法の例を教えてもらえますか?

次の関係をモデル化したいと思います。

これはすべて、メインクラスの継承を形成します...基本フォームと、いくつかの特定のフォーム..TerminationForm、別のフォーム...など...

そして、各子フォームから他のいくつかのフォーム セクションをぶら下げるつもりでした。これらの子フォームを [OneToOne] としてモデル化しました

つまり、TerminationForm が上記の FormOne に類似している場合..その下に「Staffing」があります..これがリンクです..およびその相互リンクです (注...いくつかの Staffing プロパティを抽象ベースに引き上げました。退職スタッフと休暇スタッフ)

AR がスキーマを作成すると、主キーを制約する関係を介して、TerminationForm を MasterForm に適切に関連付けます...

ただし、 TerminationStaffing テーブルに MasterFormId が含まれていても、作成されたリレーションは表示されません。これについて心配する必要がありますか？後で追加できるかもしれませんが、驚きました。

TerminationStaffing で [BelongsTo] を使用することを考えましたが、TerminationForm でどのような関係になりますか (関係は 1 対 1 です。1 対多ではありません)。

私はベースから離れていますか？

rubyonrails.org のスクリーンキャストをフォローしていました (ブログの作成)。

私は次のモデルを持っています：

コメント.rb

post.rb

モデル間の関係は正常に機能しますが、1 つのことを除いては、投稿レコードを削除すると、関連するすべてのコメント レコードが RoR によって削除されることが予想されます。ActiveRecords はデータベースに依存しないことを理解しているため、外部キー、リレーション、ON DELETE、ON UPDATE ステートメントを作成する組み込みの方法はありません。では、これを達成する方法はありますか (RoR 自体が関連するコメントの削除を処理できるのでしょうか?)。

A、B、C の 3 つのテーブルがあります。テーブル A は、B および C と (n:1) 関係にあります。通常、A には B.Id (または C.Id) とテーブル名を格納します。

例えば

それは良い解決策ですか？他の解決策はありますか？