Domanda

una domanda veloce per quanto riguarda il design del tavolo ..

Supponiamo che stia progettando un database di applicazioni di prestito. Come è ora, avrò 2 tavoli ..

Richiedente (ID richiedente, Nome, Cognome, SSN, Email ...) e

Co-richiedente (CoApplicantID, FirstName, LastName, SSN, Email .., ApplicantID)

Dovrei considerare di avere solo una tabella perché tutti i campi sono uguali .. ??

Persona (PersonID, Nome, Cognome, SSN, Email ..., ParentID (Determina se si tratta di un co-richiedente))

Quali sono i pro e i contro di questi due approcci?

È stato utile?

Soluzione

Suggerisco il seguente modello di dati:

PERSON tabella

  • PERSON_ID , pk

LOAN_APPLICATIONS tabella

  • APPLICATION_ID , pk
tabella

APPLICANT_TYPE_CODE

  • APPLICANT_TYPE_CODE , pk
  • APPLICANT_TYPE_CODE_DESCRIPTION

LOAN_APPLICANTS tabella

  • APPLICATION_ID , pk, fk
  • PERSON_ID , pk, fk
  • APPLICANT_TYPE_CODE , fk
  

Person (PersonID, FirstName, LastName, SSN, Email ..., ParentID (Determina se si tratta di un co-richiedente))

Funziona se nel tuo sistema esiste una persona ever come richiedente o co-richiedente. Una persona potrebbe essere co-richiedente di numerosi prestiti e / o un richiedente stesso - non si desidera reinserire i propri dati ogni volta.

Questo è il vantaggio di come & amp; perché le cose sono normalizzate. Basato sulle regole di business e amp; realtà intrinseca di utilizzo, le tabelle sono impostate in modo da impedire la memorizzazione di dati ridondanti. Questo per i seguenti motivi:

  1. I dati ridondanti sono uno spreco di spazio e amp; risorse per supportare & amp; mantenere
  2. L'azione di duplicazione dei dati significa che può anche essere diversa in modi sottili - capitalizzazioni, spazi, ecc. che possono portare a complicazioni nell'isolare i dati reali
  3. Dati archiviati in modo errato a causa di supervisione durante la creazione del modello di dati
  4. Previsione & amp; Flessibilità. Al momento non esiste alcuna opzione oltre a richiedente o co-richiedente per un valore APPLICANT_TYPE_CODE - potrebbe essere memorizzato senza usare un'altra tabella & amp; chiave esterna. Tuttavia, questa configurazione consente al supporto di aggiungere diversi codici candidati in futuro, se necessario, senza alcun danno al modello di dati.

Non vi è alcun vantaggio in termini di prestazioni quando si rischiano dati errati. Quello che faresti, verrà mangiato dagli hack che devi eseguire per far funzionare le cose.

Altri suggerimenti

Se il modello di dominio determina che entrambe le persone sono richiedenti e che sono correlate, appartengono alla stessa tabella con una chiave foriegn autoreferenziale.

Potresti voler leggere su normalizzazione del database .

Penso che dovresti avere due tabelle, ma non quelle due. Avere una tabella "prestiti" che ha chiavi esterne di una tabella dei candidati o che hanno solo record nei candidati che fanno riferimento alla stessa tabella.

I vantaggi :   - Semplifica la ricerca: se hai solo un numero di telefono o un nome, puoi comunque cercare, in una singola tabella e trovare la persona corrispondente indipendentemente dal fatto che sia un co-richiedente o un richiedente principale. Altrimenti dovresti usare un costrutto UNION. (Tuttavia, quando sai di cercare un determinato tipo di richiedente, aggiungi un filtro sul tipo e ottieni solo tali candidati.   - Generalmente più facile da mantenere. Di 'che domani devi aggiungere l'id tweeter del richiedente ;-), solo un posto dove cambiare.   - Permette anche di inserire persone con una "apertura / non definita" digitare e assegnare quindi come richiedente o altro, in una data successiva.   - Permette di introdurre nuovi tipi di candidati (ad esempio un garante co-secondario ... qualunque) ...

Gli svantaggi :

  • con record davvero enormi (record di più milioni di persone), potrebbe avere un leggero miglioramento delle prestazioni con un approccio a due tabelle (a seconda dell'indice e di varie altre cose
  • Le query SQL possono essere un po 'più complicate, ad esempio con due join separati nella tabella persona, uno per il richiedente e l'altro per il co-richiedente. (Nulla di intrattabile ma un po 'più complesso.

Nel complesso, il design corretto è molto probabilmente quello con un solo tavolo . L'unica possibile eccezione è se nel tempo le informazioni conservate per un tipo di richiedente stavano iniziando a divergere in modo significativo dagli altri tipi di richiedente. (E anche allora possiamo affrontare questa situazione in diversi modi, inclusa l'introduzione di una tabella correlata per questi campi extra, poiché potrebbe avere più senso; Sì, di nuovo un sistema a due tabelle, ma uno in cui i campi extra possono adattarsi e quotare ; naturalmente " insieme in termini di semantica, utilizzo ecc ...)

Entrambe le varianti presentano uno svantaggio: qualsiasi persona può essere richiedente e co-richiedente due volte e più. Quindi dovresti usare la tabella Person (PersonID, FirstName, LastName, SSN, Email ...) e i co-richiedenti (PersonID come Richiedente, PersonID come CoApplicant)

Che ne dici se ogni candidato può avere un co-richiedente - basta andare con una tabella in totale. Quindi avresti Candidati , che ha un campo chiave esterno opzionale 'coapplicante' (o simile).

Se i campi tra richiedente e co-richiedente sono identici, suggerirei di inserirli nella stessa tabella e di utilizzare un "tipo di richiedente"; campo per indicare il principale o il richiedente. SE ci sono alcune informazioni speciali sul co-richiedente (come relazione con il richiedente principale, numeri di telefono extra, altre cose) che potresti voler normalizzare in una tabella separata e fare riferimento da lì nuovamente al co-richiedente (da (co-) ID richiedente) nella tabella richiedente.

Mantieni due tabelle > 1ST ID codice tipo utente            In questa tabella è possibile mantenere il tipo di utente ovvero applicat And Co candidate Utente della 2a tabella - > qui puoi mantenere tutto il campo con colori simili con il codice del tipo utente come chiave di primo piano.           In questo modo puoi facilmente distinguere tra due utenti.

Lo so - Sono troppo tardi su questo ... L'applicazione di prestito è la tua entità principale. Avrai uno o più candidati per il prestito. Abbandona l'idea di Persona: stai creando qualcosa che non puoi controllare. Ci sono stato, l'ho fatto e ho preso la maglietta.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top