ユーザーの電子メールをユーザーのSQLテーブルの2つの別々の列で使用することは良いことですか、悪いことですか？
私はウェブ開発にかなり慣れていないので、ちょっと変な質問があります。
私は現在、個人的なプロジェクトに取り組んでおり、最終的には実際の商品化された製品になるかもしれません。
私のデータベースには、ユーザー名、暗号化されたパスワード、名、姓、名前、電子メールアドレスなどのユーザー情報を格納する「user」テーブルがあります。
ユーザーは相互にやり取りできないため（したがって、機密データのセキュリティ上の問題は発生しないため）、ユーザー名はalwaysを電子メールアドレスにすることにしました。問題は、「ユーザー名」列と「メール」列の両方があることです。現在のところ、ユーザーは自分のアカウントを作成するときに、ユーザー名とメールアドレスを入力しません。 2つのSQL列に渡される電子メールを入力します。
その後、ユーザー名とメールアドレスを個別に変更することができ、技術的には異なる場合があります。これは理想的ではないかもしれません。これによって影響を受けるコードの部分を書き換えたり、データベース構造を変更したりするなど、少しの作業が必要になります。確かにそれが必要かどうかは確かです。そのため、ここでこの質問をします。
この状況は、データ管理、セキュリティ管理、または単にユーザーエクスペリエンスのいずれかの観点から将来的に問題を引き起こす可能性がありますか？
設計によって冗長な情報を持つ意味はありません。したがって、タイトルで状況を提示する方法には「いいえ」が必要です。これは良い習慣ではありません。
ただし、タイトルでは、状況を誤って伝え、すべてのニーズを考慮に入れていない場合があります。
- 概念的には、ユーザーアカウントは必ずしもユーザーのメールではありません。厳密に言えば、2つの列は冗長ではありません。
- メールアドレスをユーザーアカウントとして使用するかどうかの決定はビジネスルールであり、ハードコーディングしないと非常に簡単に進化する可能性があります。
- 人々は時々メールを変更します。これをどのように管理しますか？簡単な方法は、古いメールアドレスでログインしてメールを変更することです。これが、1列で行う唯一の方法です。しかし、もし彼らが彼らの新しいメールのスペルを間違えたらどうでしょうか？そのため、新しいメールを依頼し、確認のために新しいアドレスにメッセージを送信することをお勧めします。 2つの列を使用すると、確認後にのみ、ユーザーアカウントを新しいメールに変更することを簡単に決定できます。
この最後の箇条書きは、ビジネスルールにもかかわらず、両方のフィールドが（少なくとも一時的に）異なる場合があり、それには正当な理由があることを示しています。これは、2つの異なる目的のために2つの異なる列を保持するための良い議論です。 YAGNI（あなたはそれを必要とするつもりではない）ではなく、YGNIBDKY（あなたはそれを必要とするがまだわからない）ではありません。
最後に、行うべきリスク評価があります。 2つの列を1つにマージするのは比較的簡単です（実際には1つの検索/置換です。テーブルとコードに異なる名前が付いている場合は2つです）。後でより柔軟なネーミングに戻すことにした場合、ユーザーIDを意味する場合と本当にメールを必要とする場合を区別することははるかに困難です。
使用しないデータベース列はモデル化しないでください。クエリで使用される列のみを定義してください。維持する必要があるものの、使用されない列は定義しないでください。未使用の列は、システムの将来の保証なしに技術的負債に追加されるためです。
@ DocBrownの関連する回答 も参照してください。要約すると、後で必要になると思うものではなく、現在必要なものをモデル化します。
[〜＃〜] yagni [〜＃〜] の他の引数も参照してください：
慣例により同一である2つの列を持つことは悪い考えですが、慣例は強制されず、スキーマに表示されないという疑問はないと思います。
より興味深い質問は、今それをきれいにするための努力を費やすかどうかです。これは技術債務として知られています。ハイテク債務に対応しないことには、たとえば次のような正当な理由があります。
- コードの領域は間もなく廃止されます
- コードのプロジェクトまたは領域は実験的なものであり、廃止または置き換えられる可能性があります（無駄のないスタートアップでのピボット）
- コードの領域の変化率は非常に低く、コードは機能します
- 変更は危険です。たとえば、ある列を別の列にコピーしたり、列が異なる「レガシー」データがあり、どれが正しいのか明確ではありませんか。
通常、それを修正する理由は逆です。たとえば、コードのチャーンの発生率が高く、テクノロジーの負債によりすべての変更が遅くなっています。