データベースの設計：4種類のユーザーですが、機能は異なりますが、個別ですか、それとも1つのテーブルですか
私には4種類のユーザーがいます：
管理者、一般ユーザー、会社、サービスプロバイダー
管理者と通常のユーザーはいくつかの属性（id .first name、last name、phone、mail）を共有します会社とサービスプロバイダーもいくつかの属性を共有します（id .company name、phone、fax、mail）
アプリケーションの他のエンティティとも相互作用して、ポストジョブやイベントなどの機能にアクセスしたり、申請したりします
それらすべてをtbl_usersのような1つのユーザーテーブルに置く方が良いですか、それとも、それぞれに個別のテーブルを作成する方が良いですか？または、（管理者と通常のユーザー）と（会社とサービスプロバイダー）の2つのテーブルに追加します。
これはエンティティの属性に関する詳細です。
何を公開するかは、アプリケーションのニーズに大きく依存します。
通常、ユーザーを連絡先情報から分離して、最大限の柔軟性を実現します。また、連絡先情報データを単一のテーブルに因数分解することをお勧めします。
ユーザー（1,1） ,1）Contact_Information
会社（1,1）---（0,1）Contact_Information
サービスプロバイダー（1,1）---（0,1）Contact_Information
ユーザーテーブルには、ログインデータと追加のis_adminフィールドが含まれます。 2つのエンティティ間にリンクが存在することで、「実在の人物」が通常のユーザーと会社の両方を表すことができるという柔軟性も得られます。
データベースで継承をモデル化する方法について読むこともお勧めします-> ---（https://stackoverflow.com/questions/190296/how-do-you-effectively-model-inheritance-in-a-データベース
私はそれらすべてを1つのテーブルに保持し、それがどのタイプのユーザーであるかを示すフィールドを追加します。いくつかの空白のフィールドがあります（たとえば、管理者と通常のユーザーにはFAX番号がない）が、これは、多くのユーザーがいて、一部のフィールドがごく一部にしか使用されていない限り、問題にはなりません。 。また、通常のユーザーがFAX番号を取得できない理由や、サービスプロバイダーが姓名を取得できない理由がないため、空白を埋めることもできます。
必要に応じて、「ユーザー」テーブルと「ユーザー属性」テーブルを用意することもできますが、少数（つまり、数百人）のユーザーにとってはおそらく価値がありません。
スキーマで異なるユーザータイプが実際に異なるロールを持たない限り、それらを1つのテーブルに保持します。次のようなフィールドがあります。
- ユーザーの種類（ユーザー、管理者、会社、プロバイダー）
- 名前と苗字
- 会社名
電話番号と住所を他のテーブルに分けて、1人のユーザーが多くの電話番号と住所を使用できるようにすることもできます（おそらく、会社に複数のオフィスがあり、ユーザーは自宅、携帯電話、勤務先の電話番号などを持っています）。技術的には問題の一部ではありません。
覚えておくべき重要なことは、ユーザータイプがテーブルのフィールドとして簡単に表現され、他のテーブルが任意のユーザーをポイントできるようにすることです。これにより、単一の関係タイプが適用されます。さらに、ユーザーはテーブル間のデータのマッピング、外部キーの更新などを行うことなくタイプを変更できます。通常のユーザーが管理者になった場合はどうなりますか？もし彼が彼の家の外で働いていて、組み込まれているなら、多分追加の労働者を雇うでしょうか？ユーザーが現実の世界でタイプを変更することは非常に現実的です。もちろん、ビジネスルールは異なる場合があります。