1

これは設計上の問題です。

小さなアプリ用のデータ モデルを考え出す必要があり、最適なアプローチを探しています。

私がモデル化しようとしているビジネスの簡略化されたバージョンには、次のエンティティがあります。

  • 割り当て: これらはプロジェクトのようなもので、開始日、終了日、および関連する人々のチームがあります。
  • Workers : これらは割り当てを実行する人々です。特定の作業者は、一度に 1 つの割り当てにのみ関連付けることができます。多くの作業者を同時に同じ割り当てに関連付けることができます (大規模なプロジェクトの場合)。
  • マネージャー: この業界には、基本的に少数のマネージャーがいて、従業員を新しい割り当てに割り当てます。

次に、マネージャーが誰が何をするか (つまり、どのワーカーがどの割り当てに割り当てられるか) を管理するために使用するWeb アプリがあります。労働者は、このアプリを使用して、割り当てに関連する費用を登録します。

そのため、Web アプリのコンテキストにはUserエンティティもあり、ワーカーとマネージャーの両方にユーザーがアプリにアクセスする必要があります。

私の質問は、この (単純な) システムをサポートするのに最適なデータ モデルは何ですか?

私はこのモデルを描いています：

  • USER (ID、ユーザー名、パスワード、...)
  • PERSON (ユーザー + 名前、電子メールなどから継承...)
  • MANAGER (person から継承 + manager のみの追加フィールド)
  • WORKER (person から継承 + worker のみの追加フィールド)

このモデルについて私が気に入らないのは、すべての人にユーザーが必要だということです。今日は労働者と管理者にそれが起こるかもしれませんが、このシステムに「顧客」を追加します。これには、サイトにアクセスしない人も関連付けられるため、ユーザーは存在しません.

より良いアプローチはありますか？おそらく継承のない標準的なアプローチはありますか？

アップデート

上記で提案したモデルに基づいて、この特定のビジネスに関する追加情報を追加すると、(基本) モデルは次のようになります。

PERSON
id
email
passmd5
role_id
firstname
lastname
...

ROLE
id
description

PERMISSION
id
description

ROLE_PERMISSION
role_id
permission_id

COMPANY
id
name
contact_name
contact_email

ASSIGNMENT
id
customer_company_id
start_date
end_date
location_lat
location_lng
location_description

MACHINE
id
brand
model
description

PERSON_MACHINE_EXPERTISE
person_id
machine_id

図全体を理解するのに役立つ、ビジネスに関する追加情報を次に示します。

  • このビジネスは、特定の顧客にサービスを提供するために、ある種の機械の専門家である人々を世界中のさまざまな場所に派遣することで構成されています。
  • 「専門家」という人がいます。
  • 「マネージャー」である人々がいます (おそらく 1 人だけですが、もっといる可能性があります)。
  • 割り当てがあります（基本的に、専門家が仕事を完了する必要がある仕事、時には複数の専門家が必要です）。
  • 人ではなく基本的に企業である顧客がいます。
  • 機械があります。
  • どの人がどのマシンの専門家であるかについての情報があります。

理にかなっていますか？これを改善できるアイデアはありますか？

4

1 に答える 1

1

継承なしでこの問題に取り組むには、おそらくPersonクラスとクラスを定義しRole、すべてPersonに s のリストRole(またはドメインのニーズに基づく単一のリスト) を持たせることができます。

マネージャーとワーカーの概念はRoleクラスに分類され、一部の人はマネージャーの役​​割 (マネージャー) を持ち、他の人はワーカーの役割を持ちます。これにより、すべてのオブジェクトの管理が簡素化Personされ、ステータスや権限などの変更がシステム内の役割の更新に削減されます。Roleまた、ソースを変更せずに新しい を追加する柔軟性も提供します。単純に の新しいインスタンスを作成しRole、たとえばCustomerを必要な人に割り当てPersonます。

最後に、別の概念を作成して、Permission何ができるかを定義する概念を呼び出しPerson、WorkerおよびManagerロールにCanAccessWebApp権限を付与する ( Customerには付与しない) ことができます。これにより、全体的な関係設計をかなりシンプルに保ちながら、長期的には多くの柔軟性が得られます.

于 2013-06-05T20:12:44.677 に答える