パスワードの変更以外にユーザー文書の編集を許可するのは悪い習慣です。yo の angular-fullstack には、ユーザーを更新する機能がないことに気付きました。また、firebase では、ユーザーは認証に登録されますが、ユーザー情報 (名前、電話、住所など) は別の場所に保存する必要があります。
言い換えれば、認証のみを担当するユーザー ドキュメントを作成し、非認証フィールド用に別のドキュメントを作成する理由はありますか?
意見を求めているわけではありません。認証フィールドと非認証フィールドを同じドキュメントに保存することに関する事実上の問題のみ。
アプリケーションのプロトタイピングを行う場合、最初にこのデータを分離することにメリットがあるとは言えません。ただし、アプリケーションが大きくなるにつれて、ID 情報を分離する理由がいくつか発生する可能性があります。
関心の分離
認証は特定のユース ケースです。認証を個別に保存することは理にかなっている可能性があります。これにより、認証ロジックを外部 ID プロバイダーに委任する必要がある場合に、認証メカニズムの変更が容易になる可能性があります。
これはどのドメインにも当てはまり、さまざまなサービスがさまざまなユーザー関連情報を処理している可能性があります。これらのサービスは、そのデータの保存とオーサリングを担当することができます。すべてのサービスがユーザーのすべてのプロパティを知る必要があるわけではないため、各サービスはそれが担当するデータを保存します。
セキュリティポリシー
機密性の高いユーザー情報を別のコレクションに入れると、データベース管理者は、その特定のコレクションにアクセスできるユーザーをより細かく制御できます。または、セキュリティ ポリシーで必要な場合は、認証を別のサーバーにまとめて移動するための基礎として使用することもできます。
あなたは意見のない回答を求めましたが、あなたがほのめかしているトピックは、関心の分離とマイクロサービスアーキテクチャに関連しています。これらのドメインは非常に独断的である可能性があるため、私の回答を完全なものと見なさないでください。
マイクロ サービス アーキテクチャについては、こちらをご覧ください:
http://martinfowler.com/articles/microservices.html