Il tuo caso sembra un'istanza di classe/sottoclasse.
Esistono due modi classici per progettare tabelle SQL per gestire le sottoclassi. Ognuno ha vantaggi e svantaggi.
Un modo è chiamato "Ereditarietà tabella singola". In questo design c'è solo una tabella per tutti i tipi di utenti. Se una determinata colonna non appartiene a una determinata riga, l'intersezione viene lasciata NULL. È possibile aggiungere una colonna per indicare il tipo di utente.
Un altro modo è chiamato "Ereditarietà tabella classi". Questa è molto simile alla risposta data da Nanego, con alcune piccole modifiche. C'è una tabella per gli utenti, con tutti i dati comuni e un campo ID. C'è una tabella per ogni sottoclasse, con i dati che riguardano quella sottoclasse. Il campo id è spesso impostato come una copia del campo id nella riga corrispondente nella tabella degli utenti. In questo modo la chiave della sottoclasse può svolgere il doppio compito, agendo sia come chiave primaria che come chiave esterna che fa riferimento alla tabella utente. Quest'ultima tecnica è chiamata "Chiave primaria condivisa". Richiede un po' di programmazione al momento dell'inserimento, ma ne vale la pena. Rafforza la natura uno-a-uno della relazione e accelera i collegamenti necessari.
Puoi cercare tutti e tre questi design come tag in SO o come articoli sul Web.
single-table-inheritance class-table-inheritance shared-primary-key
