私のER図は正しいですか？関係を使用する理由
MySQLで構築されるデータベースのエンティティ関係図（ERD）を作成したのはこれが初めてです。関連のビジネスドメインは、約機器の問題の管理です。
これ以前は、テーブル間にリレーションシップを作成することはなく、MySQLAdminでテーブルを作成して、PHP/MySQLコードでリンクを作成するだけでした。
これらの関係を作成する必要がある理由はありますか？
データベースの設計と関係について多くの情報を読みました。
私が作成したERDが正しいことを確認したいのですが。私は間違いをしましたか？またはこれを行うより良い方法はありますか？
検討中のERD
私のデータベースがすべきこと：
- チケット（issue_tickets）を作成できるユーザー（users）のリストがあります。
- 彼らは問題の説明を提供し、おそらくいくつかのファイル（issue_files）を追加します。
- 次に、他のユーザー（issue_watchers）を接続して、問題を解決します。
- すべてのユーザー（ユーザー）はチケット（issue_tickets）にコメントできます。
- チケット（issue_tickets）には、一度に1つのステータス（issue_status）しかありません。
- チケット（issue_tickets）には1つのカテゴリ（issue_category）しかありません。
- チケット（issue_tickets）には、多くのコメント（issue_comments）と多くのウォッチャー（issue_watchers）を含めることができます
- チケット（issue_tickets）には、チケットを作成した1人のユーザー（ユーザー）のみがいます。
- チケット（issue_tickets）は、1つの機器（機器）にのみ適用されます。
- ユーザーは多くのチケットを作成できます
- 機器は多くのチケットを持つことができます
アプリケーションからPK/FK関係を維持することを期待するのは非常に悪い習慣です。重要なデータベースでは、データは、アドホッククエリやデータインポートなどの他のソースから変更される可能性が100％近くあります。データベース内のデータが保護されていると考えるのは無責任です。アプリケーションには保護機能があるためです。 Webサービスなどを介してすべての変更を強制すると思いますが、実際には、購入したばかりの企業から、サービスを通じて一度に1レコードずつ、100万の新しい顧客レコードを追加することはありません。データベースは、人々がソースで直接、または他のアプリケーション（一部はWebサービスを使用できない場合がある）を介してデータベースを変更するという事実を考慮して設計する必要があります。さらに、アプリケーションインターフェイスは通常、データよりも破棄または再設計される可能性が高く、それが発生すると、データ整合性ルールのすべてまたは一部が失われる可能性があります。データベースの設計では、プログラマーや最初のアプリケーションにとって最も簡単で最も便利なものではなく、データを長期にわたって保護する方法を考える必要があります。データの専門家は、データベースにPK/FK関係を設定します。これは、データが存在する場所であり、データ品質を保護するために設定するのに最適な場所だからです。
私の現在の位置にはさまざまな会社からのデータがあり、正しく設計されたデータベースにはないデータ整合性の問題があるため、データベースにPK/FK関係を設定しなかったデータが多すぎます。
EERダイアグラムは、設計へのいくつかの追加を文書化したすべてのビジネスルールを満たしています。
a）監査目的で、チケットのアクション、つまり、チケットが開かれたとき、ウォッチャーが追加されたとき、ステータスが変更されたときなどを追跡する必要があります。
b）列の命名-users_id throughtを使用しますが、各外部キーには、たとえば、目的に応じて名前を付ける必要があります。
c）テーブルの命名-これは私のスタイルですが、singular、issue_ticketなどを使用してテーブルに名前を付けることをお勧めします