Devo evitare la duplicazione dei dati?

Question

Devo evitare la duplicazione dei dati?

#1 da (1 voti)

4

Sto provando a progettare un sistema ERP relativamente semplice. Tuttavia, ci sono alcuni requisiti che complicano un po 'le cose:

Deve essere possibile aggiungere tutti i tipi di contatti alla tabella persone , inclusi clienti e collaboratori.
Deve essere possibile assegnare un utente a un contatto, in modo che gli utenti possano accedere ai propri programmi e materiale.
Deve essere possibile assegnare gli utenti a più clienti, quando ad esempio un utente lavora per più organizzazioni.
Deve essere possibile per le diverse organizzazioni avere diversi dettagli di contatto per un utente.
Quando - in futuro - viene aggiunta una funzionalità di gestione del progetto, deve essere possibile condividere progetti tra organizzazioni.

Mi è venuto in mente questo semplice modello di dati:

Comepuoivedere,c'èunacertaduplicazionedeidatitraletabelle.

Dovreisemplicementeeliminareilnomedell'organizzazionedelclienteerecuperarlodalcampodicontattodelcliente?Esì,ilcontattodelclienteèlapersonachericevefattureesimilidanoi.Questaèunabuonadecisionediprogettazioneonondovreiusarelatabellapersoneperquesto?

Ilnomedell'utenteèunaduplicazionedelnomedelcontatto,manonpensochesiaevitabile?Nonvogliolegareidettaglidell'utenteaidettaglidelcontatto,vediilpunto4.

Ancoraunavolta,questoèsolounsemplice"mockup" per visualizzare le cose, ma che tipo di miglioramenti posso apportare a questo modello? C'è un modo più elegante?

design data-modeling erp

posta Willem-Aart 20.02.2015 - 15:56

fonte

1 risposta

Leggi altre domande sui tag design data-modeling erp

Come riconciliare "misc fix" si commette con le richieste pull? Unisci i grafici aciclici diretti riducendo al minimo il numero di nodi

score 1 · Answer 1

TL; DR; La normalizzazione è un buon approccio e se hai problemi con questo potrebbe significare che c'è un problema con il tuo approccio - prova a riprogettare il problema.

Normalizzerei il più possibile (e ragionevole) perché ciò che porta a un design migliore in generale. Ad esempio la tabella "persone" sembra più la tabella "contact_info", se è vero, probabilmente non ha bisogno di un nome.

Quindi: l'organizzazione probabilmente ha bisogno di un nome e anche la persona (a.k.a. cliente?) ne ha uno perché è qualcosa di diverso.

Infine: probabilmente gli utenti non hanno bisogno di nome, ma login (o e-mail se può essere usato come login - che ritengo sia una buona pratica perché è più facile da ricordare e non devi occuparti di già preso i nomi utente) e la password è necessaria.

Con tale design il cliente può appartenere a una o più organizzazioni (in quest'ultimo caso è necessaria una tabella aggiuntiva per quella connessione) e l'organizzazione può dafault_contact che è FK per contact_info.id o customers.id (sei il uno per decidere cosa ha più senso in questo caso).

Con un simile approccio non esiste una tabella "persone" che accetti organizzazioni, clienti e persone reali (questo è fonte di confusione) - dai il nome alle tue tabelle in base a ciò che effettivamente contengono: contatto_data, persona (dati personali), società (codice fiscale, sito web url. ecc.), utenti e, se necessario, clienti (vedi sotto).

Domande per l'individuazione della tabella dei clienti - il cliente può essere solo un'azienda o anche una persona privata? - il cliente può essere una società senza una persona assegnatagli?

Le risposte potrebbero aiutarti a determinare se hai bisogno di "is_customer" nella tabella delle persone / organizzazioni O nella tabella dei clienti con FK person_id o organization_id o entrambi.