Ho due tipi di utenti: un utente CRM e un utente di sistema. Abbiamo un record di ogni utente CRM, grazie a una sincronizzazione notturna che eseguiamo (quindi non dobbiamo colpire l'API CRM ogni volta). Abbiamo utenti di sistema che non hanno account CRM. Abbiamo anche utenti CRM che non sono nel nostro sistema. Se un utente di sistema ha un account CRM, vogliamo collegare i due account insieme. Quindi, questa è una relazione facoltativa-facoltativa.
Originariamente, ho inserito una chiave esterna nella tabella utente CRM. Questo è stato sufficiente per noi per determinare se un utente di sistema era in CRM o viceversa. Avrei potuto mettere la chiave esterna nella tabella utente del sistema con la stessa facilità. Tuttavia, c'è la possibilità che, in futuro, collegheremo anche altri tipi di account ai nostri account di sistema. Non volevo continuare ad aggiungere nuove colonne nulle alla tabella utente del sistema quando avrei potuto aggiungerle facilmente alle nuove tabelle.
Sto utilizzando Entity Framework e sembra che odi le relazioni facoltative-opzionali. L'unico modo in cui sono stato in grado di configurare questa relazione è l'utilizzo di una relazione uno-a-molti. Nell'entità utente di sistema, ho una collezione di utenti CRM. Funziona, a parte il codice necessario per dire costantemente user.CRMUsers.FirstOrDefault() che rende il codice scomodo e difficile da leggere. Andare nella direzione opposta va bene, perché l'utente CRM si collega solo a un utente di sistema singolo (o null ).
Questo mi fa pensare che forse rappresento erroneamente le relazioni facoltative-opzionali nel mio database. Non c'è una chiara ragione per cui la chiave esterna dovrebbe essere su un tavolo o l'altro. Forse una tabella many-to-many con un vincolo univoco è migliore (ma penso che significherebbe avere una collezione in entrambe le entità, schifo!).
Quindi, come dovrei rappresentare questi tipi di relazioni? EF comprenderà questa rappresentazione?