Campi / colonne dinamici

Dipenderà dalle specifiche del tuo caso, ma potrebbe essere meglio adottare un approccio basato sui metadati, in cui hai una tabella salary_properties che memorizza le coppie chiave-valore per consentire di dare a ciascun dipendente una struttura retributiva unica. Questo sarà molto flessibile, ma probabilmente puoi già dire che questo tavolo potrebbe diventare molto grande e poco maneggevole. Anche l'indicizzazione può essere un problema. Puoi anche leggere il valore-attributo-entità modello, se veramente pensi di aver bisogno di questo tipo di flessibilità. Tuttavia, l'EAV non presenta problemi.

In base al tuo esempio, non penso che i metadati o l'EAV siano realmente necessari. Penso che un tavolo stipendio stand-alone potrebbe essere sufficiente.

Salary
------
   employeeID
   salaryID
   base_amt
   bonus_pct
   bonus_type (annual or bi-annual)
   travel_expense_amt
   tel_expense_amt
   ...

Suppongo che se tu avessi molti tipi di spese, potresti volerlo suddividere in una tabella salary_expenses separata, e se tipi di spese, allora potresti voler avere una salaray_expense_type_id che si riferisce a una tabella salary_expense_types , ma altrimenti, Keep It Simple!

Il modo migliore è andare in verticale anziché in orizzontale. Ad esempio, un sistema basato su commissione che aumenta la commissione in base al numero di unità vendute potrebbe essere una tabella strutturata in questo modo:

Units    Commission
10         .01
100        .02
300        .05
1000       .10

Le "strutture salariali" fornite come esempi possono probabilmente essere replicate utilizzando una struttura simile a quella che penso tu stia descrivendo, con una tabella "stipendio" che è il "punto di accesso" per uno o più componenti, che può essere descritto in termini di tipo, quantità e frequenza:

Salary
   salaryId int PK

SalaryItem
   salaryItemId int PK
   salaryId int FK Ref(Salary.salaryId)
   description varchar(50)
   frequency int //maps to an enum in code, maybe also a FK to a lookup table
   amount money //or decimal(12,2)

Hai quindi delle regole (che possono o non possono essere persistenti nel DB) che determinano se uno specifico SalaryItem debba essere applicato allo stipendio della persona in base al valore di "frequenza" da applicare; devono essere applicati alla prima data di esborso effettiva uguale o superiore alla funzione della precedente data di esborso in base alla quale viene definita la frequenza. Questa è probabilmente la parte più difficile; definizione della funzione che determina le date in cui cade ogni frequenza e (se necessario) il monitoraggio dell'ultimo giorno in cui si è verificata tale frequenza.

Lo farei con due tabelle. Il database è meglio normalizzato e consente un'espansione semplice se necessario.

Tabella dei dipendenti: (1 è Jon; 2 è Jane)

EmployeeId    SalaryTypeId    Amount    Frequency
1             1               100       1
1             2               25        1
1             4               15        1
2             1               100       1
2             3               10        1
2             2               30        .5

Tabella dei SalaryTypes

Id   Description
1    Base Salary
2    Bonus                 
3    Travel Allowance
4    Telephone Allowance

Se ci sono molti diversi tipi di "Allowances", prenderei in considerazione la possibilità di creare un singolo tipo di stipendio "Allowance" e aggiungere una colonna Description o Note alla tabella EmployeeSalaries

Non sono sicuro di quale base di dati ti riferisci, tuttavia se utilizzi il concetto PIVOT , puoi raggiungere facilmente l'ennesimo livello del requisito di colonne dinamiche.

Nel tuo esempio un buon approccio sarebbe quello di separare Salario da Impiegato.

Un Salario non descrive un Dipendente e non deve essere archiviato nella tabella Dipendente. I dettagli dello stipendio devono essere memorizzati in una tabella degli stipendi, in cui è anche possibile registrare ulteriori informazioni sullo stipendio, ad esempio quando è stato effettuato lo stipendio e su quale sia il tasso di commissione dello stipendio, ecc.

Ci sono anche alcuni errori di progettazione di database comuni da evitare che sono ben compilati in questo post - Dieci errori comuni di progettazione del database

Modifica: gli elementi di riepilogo dettagliati devono essere conservati in una tabella SalarayItem separata. Con una relazione uno a molti tra Salary- > SalaryItem