Per l'archiviazione di persone in MySQL (o qualsiasi DB) - più tabelle o solo una?

Question

La nostra azienda ha molte entità diverse, ma una buona parte di queste entità di database sono le persone. Quindi abbiamo clienti, dipendenti e potenziali clienti, appaltatori e fornitori e tutti hanno determinati attributi in comune, ovvero nomi e numeri di telefono di contatto.

Forse sono andato fuori bordo con il pensiero orientato agli oggetti, ma ora sto cercando di creare una tabella "Persona" che contenga tutte le persone, con i flag/sottotitoli che "estendono" quel modello e aggiungono gli attributi basati sui ruoli alla giunzione tavoli se necessario. Se cresciamo a dire che 250.000 persone (su MySQL e ISAM) avranno un impatto così grande sulle prestazioni che i futuri DBA mi malediranno per sempre? La nostra singola ricerca più comune è sulle combinazioni nome/cognome.

Per, ad es. un'azienda come Salesforce, sono clienti/lead/dipendenti tutti in una tabella centralizzata con sotto-viste (per mancanza di un termine migliore) o sono separati in tabelle diverse?

Avvertenza: questa domanda ha a che fare con "è stato meglio farlo nel mondo reale" in contrasto con il progetto teorico. Mi piace la soluzione di cui sopra, e sono fiducioso che con le visualizzazioni, il corretto dimensionamento e l'indicizzazione accurata, le prestazioni non ne risentiranno. Sento anche che quanto sopra non conta come un MUCK, solo un tavolo piuttosto grande.

Answer 1

Una tabella 'persona' è l'approccio più flessibile, efficiente, e senza problemi.

Sarà facile per voi fare ricerche limitate - trovare tutte le persone con questo cognome e chi sono i clienti, per esempio. Ma potresti anche scoprire che devi cercare qualcuno quando non sai cosa sono - che sarà più facile quando avrai una tabella di 'persona'.

Tuttavia, è necessario considerare la possibilità che una persona abbia più cose per te - un cliente perché ha acquistato qualcosa e un appaltatore perché le ha assunte per un lavoro. Sarebbe meglio, quindi, avere una tabella 'join' che ti dia una relazione molte a molte.

create person_type (
    person_id int unsigned, 
    person_type_id int unsigned, 
    date_started datetime, 
    date_ended datetime, 
    [ ... ] 
) 

(Ti consigliamo di aggiungere indici e chiavi esterne, naturalmente person_id è un FK a 'persona' tavolo;. 'Person_type_id' è un FK al vostro tavolo di riferimento per tutti i possibili tipi persona I'. Abbiamo aggiunto due campi data in modo da poter stabilire quando qualcuno era quello che pensavi.)

Answer 2

250.000 record per un database non è molto. Se imposti i tuoi indici in modo appropriato non troverai mai alcun problema.

È consigliabile impostare un tipo per un utente. Questi tipi dovrebbero essere in una tabella diversa, in modo da poter vedere cosa significa il tipo (renderlo un TINYINT o simile). Se hai bisogno di campi aggiuntivi per tipo di utente, potresti davvero creare una tabella diversa per quello.

Questo approccio suona davvero buono per me

Answer 3

Dal momento che si dispone di molti "tipi" diversi di persone, in modo da avere il design normalizzato, con adeguati vincoli di chiave esterna, è meglio utilizzare il modello di supertipo/sottotipo. Una tabella Person (con comune a tutti gli attributi) e molte sottotipo (Employee, Contractor, Customer, ecc.), Tutte in rapporto 1: 1 con la tabella Persona principale e con i dettagli necessari per ogni tipo di Persona.

controllare questa risposta da @Branko per un esempio: Many-to-Many but sourced from multiple tables

Answer 4

Teoricamente sarebbe possibile per essere un cliente per l'azienda per cui lavori.

Ma se questo non è il caso, allora lo potrebbe memorizzare le persone in tabelle diverse a seconda del loro ruolo.

Tuttavia, come ha detto Topener, 250.000 non è molto. Quindi mi sentirei personalmente sicuro di conservare ogni singola persona in un tavolo.

e quindi avere una colonna per ogni ruolo (dipendenti, clienti, ecc)

Answer 5

Anche se si finisce con una soluzione di una tabella (per gli attributi della persona principale), si vorrà astrarre con viste e mettere su alcuni vincoli.

L'ultima cosa che si vuole fare è inviare informazioni riservate ai clienti che dovevano solo andare ai dipendenti perché qualcuno non si iscrisse correttamente. Oppure un cross join accidentale che porta a raddoppiare le entrate su un report (ma solo per clienti particolari che hanno anche un dipendente collegato in qualche modo).

Dipende molto da come si desidera che i livelli siano visualizzati e da quali componenti accedano a quali livelli e come.

Inoltre, vorrei pensare di voler rivisitare la scelta di MyISAM su InnoDB.