Costruire un database di contatti - Hai bisogno di una piccola ispirazione per lo schema

Question

Ho lavorato alla disposizione della struttura dei dati per un'applicazione su cui sto lavorando.Una delle cose che dovrà gestire è la memorizzazione delle informazioni sui clienti/contatti.Ho studiato l'interfaccia di alcuni diversi programmi di informazioni di contatto come Rubrica Indirizzi, contatti Gmail, ecc.

Fondamentalmente ho ridotto il contatto a una "entità" (individuo, azienda, ruolo, ecc.).

• Ogni Entità può averne multipli Indirizzo, Telefono, E-mail inserimenti.
  • Ognuno di questi definisce una “relazione” (casa/lavoro/assistente, ecc.)
  • Entità {1} --{relazione}--> {0..*} Dati
• UN Entità può averne multipli campi che sono archivi di dati a mano libera per altri dati "generici" (compleanni, account AIM, ecc.)
  • Entità {1} --{fieldName}--> {0..*} Campo dati
• UN Entità può collegarsi a un altro Entità per esempio come a dipendente, Sposa
  • Entità {0..} <--{relazione}--> {0..} Entità

Qualcuno ha eseguito implementazioni SQL di database di contatti simili?Qualche intuizione/suggerimento/insidia da evitare che potresti condividere con qualcuno che sta cercando di lavorare su un progetto da solo qui?Ciò che ho descritto sembra ragionevole o eccessivamente complicato?

Una domanda, supponiamo che tu abbia 4 persone che lavorano tutte per la stessa azienda.Hanno tutti lo stesso numero di telefono "di lavoro" (magari con un interno diverso) - Se cambia il numero o l'indirizzo di "lavoro", mi piacerebbe poter aggiornare i contatti abbastanza facilmente.Molto di questo dipende da come utilizzeresti il ​​database.Penso che si tratti di collegare i dipendenti alle rispettive entità aziendali, ma in tal caso l'indirizzo/numero di telefono non è più direttamente collegato al dipendente.Sto discutendo se rendere la relazione entità/dati molti a molti consentendo di allegare lo stesso indirizzo postale/numero di telefono a più persone e aggiornandolo in un unico posto è possibile aggiornarlo in tutti i posti.Sto pensando a questo? strappa i capelli

Answer 1

È un po' banale, ma devi conoscere i tuoi dati e cosa ne farai prima di iniziare a pensare alle tabelle.

Suggerirei di guardare Modellazione del ruolo degli oggetti (O Questo troppo) per definire il modello in un inglese semplice prima di implementare effettivamente qualsiasi tabella.Utilizzo questo plugin VS: NORMA questo genererà anche uno schema anche per te.

In alternativa, ce ne sono un sacco modelli di dati qui che potrebbe ispirarti.Questa è la "Gestione dei contatti" ma ce ne sono altre, come la sezione "Clienti".

(Volevo solo postare un'immagine..)
_{(fonte: databaseanswers.org)}

Answer 2

Questo è solo per aiutarti con la tua seconda domanda;dove l'interno telefonico appartiene effettivamente alla relazione tra persona ed entità aziendali.

Answer 3

Microsoft offre una serie di schemi di database iniziali, tra cui manutenzione delle risorse, gestione dei contatti, clienti e ordini, gestione dei documenti, e-commerce, help desk, software di monitoraggio dei problemi, controllo dell'inventario al dettaglio e cataloghi di prodotti.Vedere Schemi di database iniziali.

---

MODIFICARE (aprile 2016):Sembra che il webmaster Microsoft abbia interrotto il collegamento.Ecco il Archivio della Wayback Machine della pagina.

Answer 4

Un paio di punti che tendono a emergere nella mia esperienza..

Considera le relazioni reciproche.Ad esempio, se qualcuno viene definito dipendente di un'azienda, allora l'azienda è per definizione il datore di lavoro di quella persona.

Consideri gli indirizzi come entità a sé stanti o semplicemente come testo libero associato a una persona/luogo?In alcune applicazioni, l'indirizzo (edificio fisico, ecc.) è "reale" e nella tabella può esisterne solo uno.(Spesso utilizzando l'identificatore governativo/postale).