Erstellen einer Kontaktdatenbank - Benötigen Sie eine kleine Schemainspiration

Question

Ich habe daran gearbeitet, die Datenstruktur für eine Anwendung zu erstellen, an der ich arbeite. Eines der Dinge, die es handhaben muss, ist die Speicherung von Kunden-/Kontaktinformationen. Ich habe die Schnittstelle von ein paar verschiedenen Kontaktinformationsprogrammen wie Adressbuch, Google Mail Kontakte usw. studiert.

Ich habe im Grunde den Kontakt hinunter zu einer "Entität" gekocht (Individuum, Firma, Rolle, usw.).

• Jedes Entity kann mehrere Adresse, Telefon haben, E-Mail Einträge.
  • Jeder von diesen definiert eine "Beziehung" (home/Arbeit/Assistent, etc.)
  • Entity {1} - {Beziehung} -> {0 .. *} Daten
• Ein Entity können mehrere Felder haben, die für andere "generische" Datenfreiform-Datenspeicher sind (Geburtstage, AIM-Account, usw.)
  • Entity {1} - {fieldname} -> {0 .. *} Feld Daten
• Ein Entity kann auf einen anderen Entity verknüpfen zum Beispiel als Mitarbeiter , Ehepartner
  • Entity {0 .. } < - {Beziehung} -> {0 ..} Entity

Hat jemand irgendwelche SQL-Implementierungen von ähnlichen Kontaktdatenbanken getan? Irgendwelche Einblicke/Vorschläge/Fallstricke, um zu vermeiden, dass Sie mit jemandem teilen könnten, der versucht, selbst an einem Projekt zu arbeiten? Scheint das, was ich beschrieben habe, vernünftig oder zu kompliziert?

Eine Frage, sagen wir, Sie haben 4 Leute, die alle für die gleiche Firma arbeiten. Sie alle haben die gleiche "Arbeit" Telefonnummer (vielleicht mit einer anderen Erweiterung) - Wenn sich die Nummer oder Adresse für "Arbeit" ändert, würde ich gerne in der Lage sein, die Kontakte ziemlich einfach zu aktualisieren. Jetzt hängt viel davon ab, wie Sie die Datenbank verwenden würden. Ich denke, dass es darum geht, die Angestellten mit ihren jeweiligen Unternehmenseinheiten zu verbinden, aber dann ist die Adresse/Telefonnummer nicht mehr direkt mit dem Angestellten verbunden. Ich diskutiere die Beziehung zwischen Entity und Daten so, dass Sie dieselbe Adresse/Telefonnummer an mehrere Personen anhängen können. Wenn Sie sie an einem Ort aktualisieren, können Sie sie überall aktualisieren. Überlege ich das gerade? zieht Haare aus

Answer 1

Es ist ein bisschen banal, aber Sie müssen Ihre Daten wissen und was Sie damit machen werden, bevor Sie beginnen, Tabellen zu denken.

Ich würde vorschlagen, zu Object Role Modeling (oder this too) auch das Modell in Plain Englisch zu definieren, bevor Sie tatsächlich Tabellen implementieren. Ich benutze dieses VS-Plugin: NORMA, das auch ein Schema für Sie generieren wird.

Alternativ gibt es eine Reihe von data models here, die Sie begeistern können. Diese ist „Contact Management“ aber es gibt andere, wie zum Beispiel die „Kunden“ Abschnitt

(Ich wollte nur ein Bild schreiben ..) Contact Management http://www.databaseanswers.org/data_models/contact_management/images/contact_management_model.gif

Answer 2

Ein paar Punkte, die auftauchen, sind in der Regel in meine Erfahrung ..

Betrachten gegenseitige Beziehungen. Wenn beispielsweise jemand als Angestellter eines Unternehmens definiert ist, dann ist das Unternehmen per definitionem der Arbeitgeber dieser Person.

Denken Sie über Adressen als Entitäten an sich oder als nur freien Text, der mit einer Person/einem Ort verknüpft ist? In einigen Anwendungen ist die Adresse (physikalisches Gebäude usw.) "real" und nur eine kann in der Tabelle existieren. (Oft mit der Regierung/postalische Kennung dafür).

Answer 3

Dies ist nur, um mit Ihrer zweiten Frage zu helfen; wobei die Telefonerweiterung tatsächlich zur Beziehung zwischen Personen und Unternehmen gehört.

Answer 4

Microsoft bietet eine Reihe von Starter-Datenbanken Schemata, einschließlich Assets Wartung, Kontakt-Management, Kunden und Bestellungen, Dokumentenmanagement, E-Commerce, Help Desk, Issue-Tracking-Software, Steuerungskleininventar, und Produktkataloge. Siehe Starter Database Schemas.

---

EDIT (April 2016): Es erscheinen die Microsoft Webmaster den Link brach. Hier ist die Wayback Machine archive der Seite.