Progettazione di database per applicazioni online

-3

Sto sviluppando un portale di applicazioni online. Ma sono bloccato nel progettare le mie tabelle di database e sono incerto sull'approccio migliore da adottare.

Sfondo: come dovrebbe funzionare il portale

Lascia che ti dica uno scenario e come funziona il portale.

  • Sam si sta applicando come codificatore dati. Quindi va al portale di applicazioni online, compila il modulo di domanda e poi lo invia.

  • Ora, lo stato dell'applicazione predefinito dell'applicazione di Sam sarebbe per l'esame .

  • Lo staff delle risorse umane accede quindi al portale, controlla l'applicazione di Sam e quindi modifica lo stato in per l'intervista iniziale .

L'obiettivo è tracciare lo stato di applicazione di Sam (e di ogni candidato) dal richiedente al dipendente (se ha superato).

Le mie domande:

  1. Dovrei creare due tabelle? Stavo pensando a applicant e applicant_status , come mostrato nello schema alla fine della domanda. applicant contiene le informazioni circa il candidato, e quindi applicant_status sarebbe popolato ogni volta che lo staff delle risorse umane cambia lo stato di richiedente nel portale. In questo modo posso monitorare / registrare lo stato dell'applicazione del richiedente.
  2. Diciamo che ho implementato no. 1 domanda. Cosa succede se il richiedente applicato due volte ma per posizione diversa? Dovrei quindi inserire il suo / lei applicazione a applicant di nuovo? Ma questa volta con un altro id richiedente.
  3. O dovrei trattare ogni applicazione come unica anche per il richiedente la stessa persona anche se posizione diversa?

Spero che tu possa illuminarmi con questo. Qualsiasi suggerimento sarebbe molto apprezzato. Si prega di vedere lo screenshot in modo da poter vedere il mio attuale design della tabella.

    
posta Dan Angelo Alcanar 30.08.2018 - 08:14
fonte

1 risposta

1

1) Struttura dei dati

Se tu avessi solo una tabella ( applicant ), allora ogni candidato potrebbe avere solo uno stato (vale a dire l'ultimo). Questo non soddisfa i requisiti.

Con questa singola tabella potresti tuttavia avere un maggior numero di stati storici se dovessi avere una tabella employee che ricollega a applicant . Ma questo sarebbe ingombrante da usare e non rispetterebbe ancora i requisiti di un registro completo.

Quindi la migliore alternativa per tenere traccia del quadro completo sono certamente le tue due tabelle. Implementano una relazione uno-a-molti. Un'opzione leggermente migliorata sarebbe quella di estrarre i dati ridondanti di applicant_status in una terza tabella status con status_id e status_name

2) Diverse applicazioni per lo stesso richiedente?

Nel tuo modello attuale, non fai distinzione tra applicant e application . Se devi tenere traccia delle diverse applicazioni di una stessa persona, una soluzione facile sarebbe estrarre tutti i campi che dipendono dall'applicazione (cioè tutto tranne l'identità del richiedente) in una nuova tabella application

Poiché ora hai due entità diverse ( applicant e application ) che devi elaborare, ognuna avrà un ID diverso.

La principale difficoltà in questo scenario non è quella tecnica, ma quella aziendale: come identificare che un candidato è già registrato per un'applicazione in passato, quindi non creare un nuovo record per qualcuno che è già noto.

3) O solo le applicazioni?

A causa della principale difficoltà che ho menzionato in 2), l'approccio della sola gestione delle applicazioni, indipendentemente dalle altre applicazioni del richiedente, è certamente l'approccio più realistico.

Inoltre, potrebbero esserci anche argomenti commerciali che supportano questa scelta:

  • Perché dovrei sapere che il richiedente ha già fatto domanda in passato? Esempio: supponiamo che un candidato faccia domanda per una posizione contabile, e sia rifiutato perché non aveva la laurea finanziaria richiesta; questa informazione storica avrebbe senso per l'elaborazione di una successiva applicazione dello stesso candidato a una posizione di vendita? O ad una posizione contabile se nel frattempo lui / lei ho ottenuto la laurea mancante?

  • Nei paesi che hanno forti regole di protezione dei dati, è addirittura consentito conservare tali dati personali per un tempo molto lungo, specialmente se in futuro potrebbe creare un pregiudizio negativo?

Per evitare ambiguità in seguito, ti suggerirei di rinominare la tabella del richiedente nell'applicazione, in modo da avere un ID applicazione. È quindi più preciso su ciò che i tuoi dati rappresentano realmente.

    
risposta data 30.08.2018 - 09:18
fonte