%3F.png)
単一のエンティティを処理するソフトウェアを作成するのは常に簡単です。ただし、複数のアカウント/会社を処理するソフトウェアを設計するには、十分な注意が必要です。
現在、複数のアカウント/会社を処理するデータベース スキーマについて初期調査を行っていますが、適切なスキーマを示す Web ページまたはオープン ソース ソフトウェアを共有していただけますか?
編集：これに関する適切な用語は、マルチテナント データ アーキテクチャであることがわかりました。このアプローチを説明する Microsoft の役立つ記事は次のとおりです。http://msdn.microsoft.com/en-us/library/aa479086.aspx
ありがとう。
答え1
これは、「単一のエンティティ」よりも少しだけ複雑です。最悪のケース、つまり複数のアカウントを持つ複数の会社を想定してみましょう。会社用に 1 つのテーブル。会社 ID の外部キーを持つアカウント用に 1 つのテーブル。そして、各トランザクションにはアカウント ID の外部キーがあります。他のすべてのデータについては、1 つの会社、1 つのアカウント、または他のどのデータに属するかを決定する必要があります。つまり、従業員は 1 つの会社でしか働けないため (一般的に)、従業員は会社 ID を外部キーとして持ちます。部門は 1 つの会社に属し、同じ関係になります。
重要なのは、何が誰のものかを理解し、関係性を確立することです。非常に単純に聞こえるかもしれませんが、まさにその通りです。
確立されたスキーマを使用することで、多くの労力を節約できるかもしれませんが、その労力こそが良い結果を保証するものです。優れたデータベース設計は、すべての質問をすることから生まれます - 「従業員は複数の部署で働くことができますか？」「購入は常に 1 つの部署に請求されますか、それともコストを分配できますか？」「従業員の再配置に対して複数の承認を追跡する必要がありますか？」これは際限なく続きますが、これを行わないと、システムはユーザーを常に失望させ、無限の変更が必要になります。