Devi inviare email ai clienti una volta all'anno - il modo migliore per registrarli

Utilizzerei una tabella separata per le interazioni con i clienti, le comunicazioni e i "punti di contatto" (compresi gli invii e altri tipi di marketing). I dati sulle comunicazioni con i clienti sono generalmente memorizzati nei tradizionali CRM come entità aziendale distinta.

In DynamicsCRM , ad esempio, la "superclasse" che stai cercando si chiama Activity :

Activities are used to record a specific type of communication, as well as the subject, time and details of that communication. Activities are actions such as emails, phone calls, meetings, etc. Using activities helps you and your organization understand all of the communication your organization has had with each customer or prospective customer.

... e ogni tipo di interazione (Email, Telefonata, Riunione) è la sua "sotto-entità" di "Attività". ecc.

Se stai costruendo software personalizzato per "gestire le relazioni con i clienti", altamente suggerisco di ottenere una prova di un CRM ben consolidato (come Dynamics o SugarCRM) per vedere come questi sistemi modellano dati del cliente.

Also, for me logs feel like something that can be periodically cleared at some point in the future (a decision perhaps made by another developer not realising the impact).

Sembra che tu abbia una tabella di log esistente che ha già uno scopo diverso che è di minore importanza per il business (altrimenti nessuno verrebbe probabilmente conclusione dell'eliminazione intenzionale dei dati da esso). Se questo è ciò di cui stai parlando, ti raccomando strongmente

Non mescolare scopi diversi in una tabella!

Questo comporta un alto rischio di conflitto con questi scopi, come hai già detto tu stesso. Quindi questo esclude l'utilizzo di una tabella di log esistente e offre circa 3 diverse opzioni:

1. utilizza una colonna aggiuntiva lastContacted nella tabella Clienti

2. usa un'altra tabella, chiamiamola Contact , in una relazione 1: 1 a Customer

3. utilizza la stessa tabella Contact in una relazione 1: n

Se la tua azienda non deve memorizzare solo l'ultima data di contatto, ma una cronologia di contatti (che è ciò che includerà la tua proposta di tabella di registro), allora è chiaro che hai bisogno dell'opzione 3. Se così non è, e la tua azienda richiede solo una data di contatto, YAGNI consiglia di andare con l'opzione 1. Solo se hai una vera ragione tecnica (e non un sentimento superstizioso) contro l'opzione 1, anche se è necessaria solo una data di ultimo contatto, vai con l'opzione 2 Anche l'opzione 2 andrà bene se un Contact diventerà un'entità con diversi attributi, non solo una data, e si vorrà usarlo come un'astrazione a sé stante.

Nota anche, le prestazioni sono probabilmente molto irrilevanti qui, la registrazione delle date dei contatti una volta all'anno per cliente in un separato non dovrebbe metterti nei guai, almeno non se il tuo database è correttamente indicizzato.