0

次の情報を保存するためのデータベースが必要です。

ユーザー： FirstName、LastName、Eメール、モバイル、About / Description、Type（スタッフ/フリーランサー/クライアント）

スタッフ：タイプ（デザイナー/FE開発者/BE開発者/DB開発者/SEオプティミスト）、スタッフのランク
（マネージャー/スタッフ/従業員）、作業中のプロジェクト、作業中のアクティブなプロジェクト、アドレス、スキル（HTML / CSS / JS / ASPX / PHP/DB開発/SEO/デザイン）、ソフトウェア（Photoshop / Illustrator / In-Design / Fireworks / VisualStudio / MSQL / Wordpress）

フリーランサー：タイプ（デザイナー/FE開発者/BE開発者/DB開発者/SEオプティミスト）、作業中のプロジェクト、作業中のアクティブプロジェクト、アドレス、スキル（HTML / CSS / JS / ASPX / PHP/DB開発/SEO/デザイン）、ソフトウェア（Photoshop / Illustrator / InDesign / Fireworks / VisualStudio / MSQL / Wordpress）

クライアント：所有するプロジェクト、所有するアクティブなプロジェクト、住所（自宅/職場/請求/配達）

住所：家番号：、番地、2号線、3号線、郡、国、郵便番号、固定電話

プロジェクト：タイトル、クライアント名、開始日、終了日、期日、ステータス（アクティブ、保留、非アクティブ）、バージョン情報、開発チーム（プロジェクトに取り組んでいるフリーランサーまたはスタッフのリスト）、進捗状況（マイルストーンによって実行：設計/ FE / BE / DB / BO / SEO /展開）

基本的に私が苦労しているのは、さまざまなタイプのアドレスやユーザーなどをリンクする方法です。たとえば、ユーザーは次のようになります。スタッフまたはフリーランサーまたはクライアント、またはスタッフまたはフリーランサーもクライアントになることができます。それがデータベース形式でどのように機能するかわかりません。アドレスタイプなども同様です。

ヘルプはありますか？私は本当に立ち往生しています。前もって感謝します。

4

2 に答える 2

2

RDBMS 設計の基本について質問しています。Entity-Relationship design と呼ばれることもあります。大きな話題です。あなたはそれについての本を読みたいと思うかもしれません。

システム内の一意の各人物を説明する行を含む Person テーブルが必要なようです。

次に、各組織 (会社、コンサルタント会社、フリーランス エンティティ、顧客、プロバイダーなど) を説明する行を含む Organization テーブルが必要になる場合があります。

Person_Organization テーブルは、個人を組織に関連付けることができます。これにより、Person と Organization の間に多対多のエンティティ関係が実装されます。このテーブルには、PersonID、OrganizationID、およびその組織におけるその人物の役割を説明するフィールドを含めることができます。

連絡先情報 (住所、電話番号、電子メールなど) を含む Contact テーブルを追加できます。各行に Person ID が含まれます。

各プロジェクトの行を含む Project テーブルがあります。これには、単一の顧客を識別する OrganizationID と、プロジェクトを説明するその他の資料が含まれます。

各プロジェクトで役割を果たしている各組織の役割を持つ役割テーブルもあります。

複数の連絡先アドレスを持つ組織をどのように処理するかは、あなたに任された演習です。

こういう仕事は「賢すぎるのは間抜け」ということを覚えておいてください。

于 2012-12-31T15:05:14.580 に答える
0

これらはすべて、外部キーの概念を使用して行います。

一般に、各テーブルに、データの各行の識別子として機能する主キー列を指定することをお勧めします。ユーザーテーブルにはUserIdがあり、プロジェクトテーブルにはProjectIdがあります。

そこから、他のテーブルの列に外部キー制約を追加して、それらの行をユーザーにマップするように強制します。たとえば、Addressテーブルには、Userテーブルへの外部キーであるUserIdという列があります。このキーは、その行のアドレスが対応するユーザーに属していることを示します。

外部キー制約を構築する方法は、要件とデータ間の関係によって異なります。これは、簡単なクエリを使用して必要なすべての情報にアクセスできるようにするために理解する必要があるものです。

また、データは階層的であることに注意してください。クライアント、フリーランサー、スタッフがいて、それぞれにアドレスが必要です。しかし、これら3つはすべてユーザーでもあります。これらの各テーブルをUserテーブルにキーイングしてから、AddressテーブルにもUserテーブルにキーイングする方がはるかに理にかなっています。これにより、人間関係がより柔軟になり、理解しやすくなります。

于 2012-12-31T14:59:01.243 に答える