Tabella di progettazione per archiviare la gerarchia

La tua seconda scelta di aggiungere un ID filiale è molto simile alla relazione Dipendente - Supervisore. Stai solo unendo un tavolo a se stesso. Esistono modi per interrogare questi dati in modo ricorsivo se si hanno più livelli di filiali (questa azienda è una succursale di un'azienda che è anche una succursale di un'altra società?). Lo schema dei dati è valido anche per questo perché una singola azienda non può rientrare in più di un ufficio principale.

Non penso che le prestazioni siano un problema finché si indicizzano i dati in base a come si desidera recuperarli. Avere un sacco di indici su un tavolo aziendale dovrebbe essere un grosso problema, perché dubito che cambierai società o aggiungerai succursali spesso. Se la tua azienda è così certa da non avere più gruppi, non li vedo nemmeno con migliaia di uffici.

Se si va con la prima opzione (una tabella di diramazione), non si dovrebbe cambiare il dipendente. Il dipendente è assegnato a una società e solo perché quella società ha un ruolo come società principale o una succursale non cambia l'utente. Dovresti semplicemente interpretare quei dati in base all'azienda che ha una casa madre.

Hai considerato di aggiungere una tabella gerarchia? In questo modo, puoi avere tutti i livelli che desideri. Tutti i report possono essere eseguiti con ricorsione. Inoltre, se si desidera separare i livelli delle società (chiamiamole business unit), è possibile disporre di un libro di codici di tipi di unità aziendali (ufficio, filiale, area geografica, ...) e tutte le unità aziendali hanno il loro tipo.

Ora, non sono completamente sicuro di come si applicano i tipi di utenti qui. Se non si desidera separare i tipi di dipendenti (operativi, di gestione, ...), tutto ciò che resta da fare è la separazione dei tipi di utente. In base al tipo di utente (o al tipo di dipendente), puoi gestire la GUI per i rapporti o creare queste regole in una stored procedure.