Technische Details

Die wichtigsten Dinge dazu im Überblick:

• Die Datenbank wurde versucht, so flexibel und "redudant-vermeidend" wie nur möglich gehalten zu werden
• Vermeidung von Redundanz heißt: Verhindern von Mehrfacheinträgen der exakt selben Information, die man später evtl dann übersieht beim Ändern
• Demzufolge ist auch sehr viel zu einem hohen teil "normalisiert", also in eine extra Tabelle ausgelagert
• Implementierung eines rollen-basierenden Zugangs (ein Gast darf weniger als der eingeloggte User (zum Ändern seiner eigenen Kontakt-Daten), und der weniger als der Besitzer
• Lieber irgendwo eine N:M Beziehung mehr, als später an Limitierungen zu stoßen (es gibt evtl. Besitzer, die irgendo eben ein höheren Anspruch an die max. mögliche Anzahl an Einträgen hat. Denn auf Applikationsebene kann man dann immernoch per Klick die N:M Beziehung auf N:1 reduzieren (oder 1:N auf 1:1).

ER-Modell der Datenbank

Core (Haupt-Bestandteil der Kontaktverwaltung): Als JPG
Addons (Zusatz-Features - teilweise öffentlich mitbenutzbar): Als JPG

Zum Verständnis des speziellen ER-Modells:

• ER-Modell = Entity Relation (Beziehungen zwischen Entitäten, hier also Tabellen)
• HM = Has Many = 1:N (können aufgelöst werden und stehen dann in der Sub-Entität, werden durch Rauten angedeutet)
• HABTM = Has And Belongs To Many = N:M (können nicht aufgelöst werden, stellen also eine eigene Tabelle dar und sind deshalb auch explizit als solche dargestellt (rechteckig)
• Gestricheltes sind sekundäre Relationen, die erstmal für die reine Funktionstüchtikeit keine Rolle spielen, aber letztendlich sinnvoll sein können, wenn es um höhrere Usability (Benutzerfreundlichkeit) geht
• heller Hervorgehobenes wird noch "überdacht"