5

次のデータ スキーマがあるとします。

Usage
======
client_id
resource
type
amount

Billing
======
client_id
usage_resource
usage_type
rate

この例では、複数のリソースがあり、それぞれがさまざまな方法で使用できるとします。たとえば、1 つのリソースはwidget. Widgets編集することができfoo、編集することができますbar。 s はed およびedGizmoにすることもできます。これらの使用タイプは異なるレートで請求され、クライアントごとに異なるレートで請求されることもあります。(リソースの) 使用が発生するたびに、Usage テーブルに記録されます。各請求レート (クライアント、リソース、およびタイプの組み合わせ) は、請求テーブルに格納されます。foobar

(ちなみに、このデータ スキーマがこの問題にアプローチする正しい方法でない場合は、提案をしてください。)

Ruby on Rails と ActiveRecord を使用して、has_manyBillings から Usages への関係を作成し、特定の請求レートの使用インスタンスのリストを取得することはできますか? has_many, :through私が知らないの構文はありますか?

繰り返しますが、私はこの問題に間違った角度からアプローチしている可能性があるので、より良い方法を思いつくことができれば、声を上げてください!

4

2 に答える 2

6

Composite Primary Keysをサポートして Rails の ActiveRecord を拡張するプロジェクトが sourceforge にあるようです。この拡張機能は使用していませんが、役立つかもしれません。これは ruby​​forge の宝石でもあります。

プレーンな Ruby on Rails は、バージョン 2.0 の時点で、複合主キーをサポートしていません ( HowToUseLegacySchemasを参照)。すべてのテーブルには、" " という名前の単一列の自動インクリメント キーが必要idです。

私が見た説明は次のとおりです。「レガシー データベースを使用する場合は、複合主キーのみが必要です。」もちろん、これはデータ モデリングに対するばかばかしいほど無知な見方です。

私が見る解決策は次のとおりです。

  • Usage.client_id -> Client.id
  • Usage.type_id -> Usagetype.id
  • Usage.resource_id -> Resource.id
  • Billing.usage_id -> Usage.id
  • Billing.client_id -> Client.id
  • Billing.type_id -> Usagetype.id
  • Billing.resource_id -> Resource.id

Billing部分的な参照整合性を強制しようとする明らかに冗長な外部キー。しかし、うまくいきません。Billing テーブルの参照行の行と一致しない、間違った client/resource/usagetype の組み合わせでBilling行を参照する行を作成することを防ぐことはできません。Usage

編集: @Yarik: はい、その通りです。Usageを参照する方が理にかなっていますBilling。

  • Usage.billing_id -> Billing.id

うーん。ER図を作成しましたが、画像として挿入できません。

于 2008-11-11T02:31:17.920 に答える