0

Yii フレームワークを使用してインターンシップ用のデータベースとマッチング Web サイトを設計しており、主に PHP で作業しています。私たちの目標は、管理ユーザーが表示したい情報を完全に柔軟にできるようにすることです。そのため、アプリケーションを動的に保つようにしています。このため、アイデアは、コード内ではなく、データベース内のオプション/データに対するものです。現在、作業中のセットアップがありますが、それが正しい方法であるかどうかはわかりません。長文、ごめんなさい。現時点では、次のものがあります。

関係
+ ユーザーHAS MANYuser_phone
+ user_phoneHAS MANYユーザー
+ user_phone HASuser_phone_type

テーブル
user <-- user_phone_assignment --> user_phone --> user_phone_type

user_phone_type
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
limit INT NOT NULL

基本的なユーザー プロファイル情報は user に格納され、家族や兄弟のインスタンスで繰り返されるデータを減らすために、user_phone には潜在的な多対多の割り当てテーブルがあります。user_phone_type のアイデアは、「自宅」、「職場」、「ファックス」、「その他」などの名前を保存することです。

user_phone_type.limit < 0
+ フィールドが無効、actionCreatePhone では表示されない
user_phone_type.limit = 0
+ フィールドが有効、無制限のエントリが許可され、常に表示される
user_phone_type.limit > 0
+ フィールドが有効、count( user_phone) < user_phone_type.limit の間表示される

このシステムは潜在的に実行可能だと思いますが、これがこれを回避するための最良の方法であるかどうかはわかりません. 簡単な関係を維持しながら、アプリケーションを柔軟でデータベース指向に保つための他のオプションはありますか? おそらく、ある種の構成テーブルのセットアップと、構成値をモデルまたはコントローラー内のローカル変数に格納できます。

4

1 に答える 1

1

正規化には注意してください。潜在的な多対多の関係のように見えるいくつかのものは、実際には単なる属性です。電話番号と住所は、多対多でモデル化できますが、電話番号と住所の変更に対処する必要があるため、そのシナリオでは管理が難しい場合があります。住所または電話番号が変更されたときにユーザーが同じ数の住所または電話番号を使用する 1 対多のモデルでは、テーブルでそれを更新するだけです。多対多モデルで住所または電話番号が変更された場合、変更されているのが住所なのか、特定の住所へのユーザーの割り当てが変更されているのかを判断する必要があります。人々がこれを実装しようとしているのを見てきましたが、通常は郵送先住所と顧客住所、または自宅の電話と携帯電話を割り当てているため、常にバグが発生します。

電話番号を使った簡単なシナリオを試してみましょう:

ユーザー＃1の職場の電話番号は513-555-1234で、彼の携帯電話番号は513-555-4321だとします。user#2 が同じ職場の電話番号 513-555-1234 と携帯電話番号 513-555-4322 を持っているとします。

ここで、ユーザー#1 が勤務先の電話番号を削除するか、別の番号に変更するとします。番号を削除する場合に行う必要があるのは、ユーザーと電話番号の間のリンクを削除することです。電話番号フィールドを削除すると、ユーザー #2 は職場の電話も失うためです。ここで、リンクを解除したばかりのユーザーがその電話番号を指していた最後のユーザーだった場合にどうするかを決定する必要があります。電話番号を削除しますか、それとも他の誰かが拾った場合に備えて保持しますか? 電話番号の変更はさらに複雑です。変更が無効な電話番号の修正であるかどうかを知る方法はなく、それに関連付けられているすべての人に対して変更する必要があるため、電話番号への変更がすべての人に対して変更されるかどうかを判断する必要があります (最終的には悪い考えです)。ユーザーが転職して勤務番号が変わると、ユーザーの元の職場の他のすべてのユーザーも同様であり、これは明らかに間違っています)、または電話番号の変更がそれに割り当てられた 1 人のユーザーのみに影響する場合。1 対多のアプローチの動作を模倣するため、標準のユーザー メンテナンス UI に基づくおそらく最良の選択です。ただし、電話番号を変更するだけでなく、電話番号のリンクを削除してから、新しい電話番号レコードを作成して、顧客をそれにリンクする必要があります。どちらの場合も、新しいレコードを挿入するだけでなく、新しい電話番号が存在しないことを確認する必要もあります。存在する場合は、新しい番号を作成してそれにリンクするのではなく、ユーザーを新しい番号にリンクするだけです。そして、その複雑さによって何が救われるのでしょうか? あまりない。あなたがそのようなことをしたとしても、住所を確認するのに少し時間がかかるかもしれません。あなたの電話番号の 1% が勤務先の電話番号と重複するわずかなスペースかもしれませんが、最近では勤務先の電話の大部分が直接ダイヤルされているため、実際の節約にはならないかもしれません。アドレスが別のファイルに分割され、まったく管理されていないのを見たことがあります。重複しているかどうかに関係なく、新しいアドレスが追加されただけで、アドレスを親テーブルに配置するだけで節約できませんでした。

したがって、私の意見は、この質問が生成するのはこれだけですが、電話番号や住所を別のテーブルに入れることについて心配する必要はありませんが、可能性のある住所や電話番号の多くがこれらの場合、空白の住所レコードを書き込まないことを確認してください。また、それらを別のテーブルに保持する場合でも、(多対多の関係を使用して) 重複を削除する必要はありません。これは、アプリケーションに不必要な複雑さを追加するだけだからです。

于 2013-07-22T20:44:41.103 に答える