0

プロジェクトを開始したばかりで、正しい方向に少しプッシュする必要があります。これが私のテーブル構造です：

users         departments     sub-departments
-------       -------         -------
id            id              id
name          name            name
email
password
created
modified

posts         photos        profiles
-------       -------       -------
id            thumbnail     id
content       large         photo_id
created       created       user_id
user_id       profile_id    department_id
profile_id    id            sub-department_id

プロファイル テーブルには、重要でないフィールドが 5 つほどあります。これのいずれかが少しずれているように見える場合は、おそらくそうです。

users have one department
users have one sub-department
users have many posts
users have one photo
users have one profile

私が「やりたかった」ことは、必要なすべてのテーブルを作成し、それらをすべて外部キーを使用してプロファイル テーブルの下にまとめることでした。私のプロファイル モデルのCakePHPスニペットは次のようになります。

var $belongsTo = array('User', 'Department', 'Sub_Department', 'Photo')
var $hasMany = array('Comment');

もし今あなたが「なんてこった？」と思っているなら..私はあなたと一緒にそこにいます。この協会は足場で機能します。しかし、実際にロジックをプラグインし始めるときにトラブルに遭遇したくありません。

私はまだERDとCakePHPに慣れていません。$this->Profile->User->find('all', array('contain' => ....)); のように、User に属し、そこから ProfilesController クエリの下ですべてを宣言する必要があります。?

この時点で少し迷っています。どんな助けでも大歓迎です。これをどのように実装しますか？

4

3 に答える 3

3

あなたが言った：

  • ユーザーには 1 つの部門があります
  • ユーザーには 1 つのサブ部門があります
  • ユーザーは多くの投稿を持っています
  • ユーザーは 1 枚の写真を持っています
  • ユーザーは 1 つのプロファイルを持っています

おかしな用語ですが、ユーザーは 1 つの部門で働いており、実際には 1 つのサブ部門で働いています。サブ部門はおそらく 1 つの部門の一部であるため、部門とサブ部門の両方をプロファイル テーブルに記録する必要はありません。実際、両方を記録すると、強制する複雑な制約が生じます。したがって、あなたが私たちに伝えていないことがない限り、プロフィールに部門は必要ありません. ただし、実際には部門とサブ部門の間に相互参照がないことに注意してください。したがって、1 つのサブ部門が明らかに複数の部門に関連付けられている可能性があります。部門 1 で働いている人と部門 2 で働いている別の人。

「ユーザーが一度に 1 枚の写真しか持っておらず、プロフィールも 1 つしか持っていないのなら、なぜそれらをユーザー テーブルから分離するのですか?」と尋ねたくなりますが、それらを分離しておく理由がいくつかあります。

テーブルのモデリングにおける重要なポイントの 1 つは、自然主キーを識別することです。ID 列はカウントされません。またはカウントできますが、他にどのような列の組み合わせを一意にする必要があるかを判断する必要があります。たとえば、プロファイル テーブルには、プロファイル ID がありますが、指定したルールに従ってユーザー ID は一意である必要があるため、実際にはプロファイル ID は不要であり、実際にはスペースの無駄です (2 回。データ列、およびその上に作成されるインデックスに対して 1 回)。ここで、ユーザーが時間の経過とともに複数のプロファイルを持つ可能性があり、プロファイルに有効期間などがあると判断した場合、プロファイル ID 列は理にかなっていますが、最後の箇条書きはもはや有効ではありません。

posts テーブルに、ユーザー ID とプロファイル ID の両方を記録するのはなぜですか? 繰り返しますが、明確な利点を強制する複雑な制約を与えます。プロファイル ID で十分です。そこからユーザーを見つけることができます。

ユーザーは 1 枚の写真を持っていると言いますが、それはあなたがモデル化したものではありません。「各プロファイルには写真があり、写真は 1 つのプロファイルでのみ使用されます」をモデル化しました。同様に、実際には、「ユーザーには 1 つのサブ部門がある」というモデルを作成していません。「プロファイルには1つのサブ部門があります」をモデル化しました。ずさんな定義の問題である可能性が最も高いですが、ずさんな定義はずさんなデータベースにつながり、ずさんなデータベースは不正確な回答やパフォーマンスの低下につながるため、注意が必要です。

これらの問題を修正すれば、より実用的な設計に向けて長い道のりを歩むことができます。ただし、このアウトライン スキーマに存在する異常をすべて発見したかどうかはわかりません。

于 2009-10-31T02:57:00.567 に答える
2

サンプルのスキーマ/図を用意しましたので、ご覧ください。

注意すべき点がいくつかあります。Post モデル ( posts テーブル ) にはフィールド slug があります。Sluggable 動作を使用して、ここでスラッグの作成を処理します。

Department モデル ( departments テーブル ) には department_id という名前のフィールドがあり、これはparent_id である必要がありますが、ビルダー ツールはエラーをスローします。必要に応じて変更してください。lft、rght、parent_id フィールドは Tree Behavior に対応します。部門モデルでツリー動作を使用すると、部門が任意に「親」部門に属することができます。これにより、サブ部門は実際には別の部門の ID に設定された parent_id を持つ部門であるため、sub_departments テーブルが必要なくなります。

ユーザーに添付されたプロファイル、および写真 habtm プロファイルにより、ユーザーに無制限の数の写真を添付できます。認証コンポーネントに必要なものだけを使用して、ユーザー モデルをスリムに保ちたいと考えています。Profile Model は、first_name、last_name、age、city などを保持する場所です。

Photo Model で Upload Behavior ( MeioUpload ) を使用して、アップロードを自動的に処理します。

これは、設計を修正するための適切な出発点となるはずです。

http://cakeapp.com/sqldesigners/sql/centro

パスワード：セントロ

于 2009-11-03T19:08:21.657 に答える
0

CakeApp.comで CakePHP データベースの設計コンセプトをライブ テストできます。

于 2009-10-31T21:05:15.140 に答える