Project Billing という製品のデータベースの再設計に取り組んでいます。テーブル名が思いつかなくて困っています。古いデータベースでは、名前は非常にわかりにくかった ( PRB_PROJ_LVL) ため、古いものは役に立ちません。データベースは小さい (10 テーブル程度) ですが、時間の経過とともに大きくなります。
ここに問題Projectsがあります - エンティティ (およびテーブル) ですが、単語は形容詞としても使用されます。例
Project- プロジェクトを含むテーブル。ProjectTask- プロジェクト タスクを含むテーブル。これは の子ですProjects。ProjectTemplate-の子ではないプロジェクト テンプレートのテーブルProjects。プロジェクト テンプレートは、大量のProjectTasks.ProjectTaskでは、それが の子であるProjectが、そうではないことをどのように示すのProjectTemplateですか? いつもありがとう。
スキーマとその使用目的の内部ドキュメントは、これを行うためのより良い方法の1つです。命名規則だけに依存することは、常に解釈の可能性を残します-明示的な定義はそれをしません。そうは言っても、モデル（あなたの場合はテンプレート）として使用することを目的としたいくつかのオブジェクトを定義しました。これらのモデルオブジェクトは、本番アプリケーションで使用したり直接操作したりすることはできません。また、変更されたモデルに基づく新しいオブジェクトを使用して、時間の経過とともに変更することができます。自己記述性を適用しようとした1つの方法は、スキーマの導入でした。同じモデルオブジェクトを使用できるさまざまな部門があったため、次のようなものがありました（あまり想定せずに質問に適用するように調整されました）。
[dept_X]。[プロジェクト]
[dept_X]。[project_tasks]
また、アプリケーションやユーザーが直接使用することのないテンプレートの場合（たとえば）：
[モデル]。[プロジェクト]
[モデル]。[project_tasks]
開発者向けのプログラミングリファレンスとして、スキーマ定義スクリプトには、オブジェクトの関係を説明するドキュメントが含まれています（オブジェクトが外部キーなどを介して内部的に行うように）。追加の手段として、プロジェクト別にソートされたすべての新しいオブジェクトに対してwiki記事が生成されます。この新しいシステム（私のオンボーディング）の前に存在していたオブジェクトは、変更されたとき、または時間の許す限り、どちらか早い方で文書化されます。