mySQL - Datenbankdesign so ok?

F

fritz schneider

Mitglied
Hallo zusammen,

Ich habe vor eine Immobilien-Datenbank zu programmieren, dazu haben ich ein Datenbankdesign entworfen und wollte euch um Anregung, Kritik und Verbesserungsvorschläge bitten.

Kurze Erklärungen zu den Tabellen:

dokumente
hier werden alle Kundenbriefe (Word-Dokumente - Nur die Pfade zu den Dokumenten) gespeichert.

kundendaten
Hier werden alle relevanten Datensätze zu dem Kunden gespeichert zusätzlich gibt es eine Rechnungsadresse (kRStrasse, kRPLZ, kROrt) und eine Versandadresse (kVStrasse, kRPLZ, kVOrt).

letzterkontakt
In der Tabelle letzterkontakt hat man die Möglichkeit alle Zeitpunkte zu erfassen, an denen man mit dem Kunden Kontakt hatte.

objektbilder
In der Tabelle werden Bilder zu den Objekten gespeichert (Ebenfalls nur die Pfade).

objekte
Hier werden alle Immobilien und derern relevanten Daten gespeichert.

objekttypen
hier sind die verschiedenen Objekttypen enthalten, also zum Beispiel Wohnung, Haus, Bungalow etc.

rel_kundenobjekte
Hier werden alle Interessierte Kunden für ein Objekt eingetragen. Die Tabelle ist eine Relation zwischen der der Kunden ID und der Objekt ID.

Falls noch Fragen sind, bitte Fragen ich antworte so schnell wie möglich

Mir ist das Projekt sehr wichtig, deswegen würde ich mich sehr über Feedback freuen hier findet ihr auch noch mal ein Bild des Datenbankdesigns:

Ciao fritz

dbdesign.gif
 
Hallo Fritz,

an sich finde ich das Design gut, was ICH vielleicht anders machen würde, wäre die Tabelle rel_kundenobjekte.

Würde es da nicht reichen bei 'kundendaten' die oID´s einzutragen?

Wenn Du in 'kundendaten' ein Feld einfügst, wo alle Objekt-IDs hinterlegt sind (durch Komma getrennt) für die sich der Kunde interessiert, könntest Du sie bei 'objekte' durch eine DO LOOP Schleife einfach auslesen.
'rel_kundenobjekte' sieht für mich irgendwie doppelt-gemoppelt aus.:)

Gruß

Torsten
 
Original geschrieben von xthetronx
an sich finde ich das Design gut, was ICH vielleicht anders machen würde, wäre die Tabelle rel_kundenobjekte.
Zum Vergrößern anklicken....
Gleiches gilt für mich auch.:)
Du kannst den Primary Key über oID und kID zusammen legen, dann brauchst du keinen extra Schlüssel und du hast die Gewissheit, dass keine Kombi zwei mal (oder öfter) vorkommt.
Ich persönlich hätte die Tabelle letzterkontakt einfach nur kontakt genannt, da ja auch die Kontakte davor drin stehen...
 
Hallo,

wenn du dir nur den letzten Kontakt speichern willst, dann kannst du den dirket in die Kundendaten aufnehmen und sparst dir eine Tabelle... Wenn du jedoch die "History" speichern willst (so les ich das raus), dann würd ich die Tabelle umbenennen und noch ein Textfeld einbauen, da das reine Kontaktdatum doch wenig infos liefert...

bye
 
Hallo Fritz,
finde das Design sehr gut. Was aus meiner Sicht fehlt ist eine Art Status zu der Kunden-Objekt-Beziehung - es sei denn, es sind immer nur Interessenten und wenn ein Kunde kein Interesse mehr hat oder gar einen Zuschlag gegeben hat, dann wird der Beziehungs-Datensatz gelöscht. Ich nehme aber an, dass da mehr dahinter stecken soll.

Mögliche Stati könnten sein "Angeboten", "Interesse bekundet", "Besichtigt", "Vorgemerkt/Reserviert", "Abgeschlossen", usw. - je nach Bedarf.
Recht einfach und starr ließe sich das über ein zusätzliches Feld in rel_kundenobjekte (idealerweise SET oder ENUM) realisieren. Oder etwas ausgefeilter mit einer zus. Tabelle "kundenobjektstati" (ähnlich Deiner Tabelle "objekttypen").

Außerdem kann es manchmal nützlich sein, Kundendaten in mehrere Tabellen aufzuteilen, vor allem wenn aus dem Projekt mal mehr werden soll. Ich denke da an beispielsweise eine eigene Tabelle "kundenanschriften" wo nur die Adressen gespeichert werden (vielleicht hat ein Kunde mehrere Anschriften). Das macht das Ganze natürlich komplizierter, es lässt sich dann aber auch leichter erweitern.

Viele Grüße und viel Spaß bei der Realisierung,
Martin
 
Ich find das mit der Relationen Tabelle schon ganz gut, um die n zu n Beziehung aufzulösen.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück