0

顧客から送られてきたメッセージを保存するテーブルを見てみましょう。たとえば、顧客が私たちに送信した通信への応答を送信するように要求した場合も、そのテーブルに格納したいとします。彼らが応答を要求した場合、私たちは彼らの電子メールアドレスと予想される日付を記録することによってその情報を保存します。彼らが返答を望まないのであれば、私たちは彼らの電子メールアドレスを必要としません。

Correspondences
    Primary_key
    Content
    Date
    Response_expected
    Return address
    Return date

または、response_expected列を完全に削除して、nullの差出人住所/差出人住所は「応答が期待されない」ことを意味し、null以外の差出人住所は応答が期待されることを意味することに同意できます。アプリケーションは、明示的な「応答が必要ですか？」をチェックするのではなく、このロジックを使用する責任があります。分野。

（この質問のために、期待される応答がyesでない限り、差出人住所と日付がnullでなければならないという制約があると仮定します...私のポイントは、この列が誤用されたり、別の目的に使用されたりしないことです）

私の質問は次のとおりです。アプリケーションがデータを解釈する特定の方法に同意する必要があるこの種の設計は受け入れられますか？一方、返信を期待していない場合は差出人住所と日付が確実にわからないため、必要以上のデータを保存しています。

4

1 に答える 1

2

今のように、Response_Expected用に別の列があります。はい、応答が期待されない場合は差出人住所がNULLになるため、冗長な情報が含まれている可能性があります。

ただし、2つのアイデアは異なります。検討する可能性のあるいくつかのシナリオを次に示します。

  • 将来的には、応答を返す方法は複数あります。メールは1つのチャネルにすぎません。これによりデータ構造が複雑になりますが、ロジックは単一のチャネルに依存します。
  • メールを送信しましたが、バウンスするか、その他の理由で配信できません。
  • 応答は他のいくつかの基準に依存するようになります。彼らは応答を望んでいますが、それは特定の条件下でのみです。

データの重複については心配しません。アプリケーションの持続可能性についてもっと考えたいと思います。

于 2012-09-04T22:04:24.670 に答える