Il numero 2 sarebbe raccomandato dalla maggior parte delle persone, me incluso. Non tanto perché sono "cose" diverse, ma perché stai modellando una relazione tra i due.

Anche se la prima opzione funzionerebbe, funzionerebbe solo nei casi in cui un cliente ha un solo datore di lavoro e ogni cliente ha un diverso datore di lavoro.

Non funzionerebbe nei casi in cui un cliente ha più di un datore di lavoro. E se più di un cliente ha lo stesso datore di lavoro, il datore di lavoro dovrebbe essere elencato due volte (o più) nel database. Ciò porterebbe a dati ripetitivi e complessità nel tentativo di aggiornare i loro dettagli. Meglio romperli in due tavoli.

Un altro approccio che potresti prendere è di avere 3 tabelle: una per la distinta lista di singoli clienti, una per la distinta lista di datori di lavoro, e poi un'altra che collega clienti e datori di lavoro. Ciò consentirebbe di modellare casi in cui i clienti hanno più di un datore di lavoro, lo stesso datore di lavoro ha più di un cliente e casi in cui un cliente non ha un datore di lavoro.

Uno dovrebbe sempre sforzarsi nei propri progetti per non fare supposizioni ingiustificate che potrebbero tornare a mordere uno nel proprio didietro.

Al giorno d'oggi, almeno negli Stati Uniti, l'assunzione di un datore di lavoro per dipendente è MOLTO ingiustificata. Possono benissimo avere datori di lavoro ZERO, possono avere fino a tre datori di lavoro.

Con questo in mente, lo schema 2 è di gran lunga migliore, in quanto non ti blocca QUITE in un'assunzione 1-1.

L'opzione 2 è l'approccio corretto. Hai la tua chiave esterna indietro, anche se la tabella client dovrebbe avere un campo EmployerID dal momento che hai detto che un cliente avrà un solo datore di lavoro e molti clienti potrebbero avere lo stesso datore di lavoro. Questo è un problema di normalizzazione del database e l'obiettivo della normalizzazione del database è ridurre l'inserimento, l'aggiornamento e l'eliminazione delle anomalie che possono verificarsi e può essere molto costoso, se le tabelle non sono correttamente normalizzate. La normalizzazione può rallentare le istruzioni di selezione anche se su tabelle grandi, nella maggior parte dei casi la differenza tra le tabelle normalizzate e le tabelle non normalizzate sarà così piccola che è impercettibile.

è possibile attenuare l'hit per selezionare le query creando viste, ma ciò potrebbe non essere possibile a seconda della frequenza degli aggiornamenti. La regola generale per la progettazione del database è di normalizzare il più possibile e quindi denormalizzare come richiesto dalle prestazioni.

A mio parere, a meno che non si abbia una qualche ragione per abbandonare buone pratiche di database relazionali (come esigenze estreme di ridimensionamento o simili) si dovrebbe seguire buone pratiche di database relazionali anche se si pensa che i requisiti odierni non lo forzino. Detto questo, penso che le tue tabelle individuali dovrebbero contenere solo le colonne relative al concetto che stai cercando di modellare con quella tabella.

Un datore di lavoro è sicuramente un concetto separato dal cliente, quindi mescolarli nello stesso tavolo è ... problematico. Funziona? Certo, per un po '. Ma alla fine sarà un problema.

Stai andando nella direzione giusta rimuovendo i dati del datore di lavoro dai dati del cliente, ma vorrei fare un ulteriore passo avanti e creare anche una tabella Address . Quindi, il tuo schema sarebbe più simile a:

Client Table
------------------ 
id int
name  varchar(255),
email varchar(255),
employer_id int,
address_id int

Employer Table
---------------------
id int
name varchar(255),
phone varchar(255),
address_id int

Address Table
---------------------
id int
address varchar(255),
city varchar(255),
state char(2),
zip varchar(16)

Ora le tabelle sono molto più semplici.

E, quando alla fine dovrai aggiungere ulteriori informazioni (pensa a "delivery_instructions" per un indirizzo o qualche attributo specifico del datore di lavoro) avrai un posto appropriato per metterlo.

Perché dovresti prendere questa decisione? O il cliente desidera / ha bisogno della capacità di:

1. Assegna più datori di lavoro a ciascun cliente.
2. Avere dati coerenti su un datore di lavoro (cioè cambiare il numero di telefono in un unico posto per tutti i dipendenti)
3. Traccia l'occupazione nel tempo (simile a più datori di lavoro, ma deve essere concepita come "attuale datore di lavoro").
4. Cosa succede se hanno bisogno di espandere i dati per i datori di lavoro? Ad un certo punto sarebbe meglio stare nella sua tabella

oppure no. Quanto è importante l'informazione dell'indirizzo? Che tipo di report / aggregazione si aspettano?

Se ritieni che questo sia complicato, attendi fino a quando non trovi che ciò richiede davvero una terza tabella per creare una relazione molti-a-molti.

Come al solito ...

Dipende

Entrambe le strutture potrebbero essere valide, a seconda di cosa farai con i dati .

Se hai solo bisogno di una tabella di 'dump' per un rapporto veloce del cliente corrente + informazioni sul datore di lavoro, allora la prima disposizione va bene.

Se stai modellando un sottoinsieme semplicistico del mondo reale, dove ogni cliente ha zero o un datore di lavoro, sarà sufficiente la seconda disposizione (anche se il cliente dovrebbe indicare al datore di lavoro e non viceversa).

Se stai mantenendo un modello più "reale", dove il tempo conta , allora cliente e azienda potrebbero essere tabelle separate, con una terza tabella per la relazione tra dipendenti e dipendenti che include l'inizio -dati e date di fine data; le persone cambiano di tanto in tanto i datori di lavoro;)

Se vuoi un modello minimale, non ridondante (anche orientato agli oggetti ), allora noterai che stai memorizzando quasi esattamente le stesse informazioni sul cliente e sulla società, che potrebbero essere generalizzate ad un singola tabella aziendale. Un'altra tabella potrebbe notare che alcune delle aziende sono i tuoi clienti, mentre un'altra tabella dovrebbe prendere nota della relazione employee-by.

Quest'ultimo è probabilmente meno ridondante e più "reale" rispetto agli altri modelli, ma può essere più difficile da interrogare e mantenere.

Il che ci riporta a: che cosa, esattamente, stai andando a fare con questi dati?