nicht angemeldet
Immobilien DB - Ist das Datenbankdesign OK?
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 Morpheuz
<img src="http://www.morpheuz.net/host/dbdesign.gif" border="0" alt="">
-
hi,
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:
[...]Falls noch Fragen sind, bitte Fragen ich antworte so schnell wie möglich.
Keine weitere Fragen.
Tipp: _Dein_ DB-Design sollte _Deinen_ Anforderungen genügen.
Gruss, Rolf
--
KnowHow veröffentlichen statt patentieren!-
hi rolf,
danke für deinen beitrag, aber das hilft mir leider nicht weiter. Das ist mein erstes größeres Projekt und da möchte ich nicht die Wichtigsten Sachen vergessen und möchte gerne dazu lernen.
Ciao morpheuz
-
Hallo,
nun wenn das dein erstes größeres Projekt ist wirst Du allerhöchstwarscheinlich zu Anfang nie ein 100%tig passendes Datenbankdesign hinbekommen. Es geht so schnell das einem bei der Entwicklung noch Sachen einfallen, oder empfohlen werden - da müssen bestimmt noch einige "Alter Table" o.a. herhalten.
Gruß Helmut
-
-
-
Hallo,
dokumente
hier werden alle Kundenbriefe (Word-Dokumente - Nur die Pfade zu den Dokumenten) gespeichert.Mich würde auch interessieren, was so grob im Dokument drin steht, ohne es öffnen zu müssen, und wann es angelegt wurde, eventuell auch zu welchem Anlass.
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).Versandadresse bei Immobilien finde ich witzig;-)
Gerade wenn es um Immobilien geht, würde ich mir überlegen ob ich die Adressen nicht mit einer 1:n oder m:n-Beziehung zu den Kunden ablegen würde, da ja das Klientel günstigenfalls, bei positiven Abschluss, auch umzieht.
Ausserdem gehe ich davon aus, dass hier auch die Anbieter abgelegt werden.letzterkontakt
In der Tabelle letzterkontakt hat man die Möglichkeit alle Zeitpunkte zu erfassen, an denen man mit dem Kunden Kontakt hatte.Hier wäre interessant was genau bei dem Kundenkontakt passiert ist, also Kontakttyp, Bemerkung, wo usw.
objekte
Hier werden alle Immobilien und derern relevanten Daten gespeichert.Interessiert es Dich nicht, ob das Objelkt jemand angeboten wurde und wie weit die Verhandlungen bez. Verkauf/Vermietung schon sind.
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.Hier könnte auch interessant sein, _wie_ das Objekt in Beziehung zum Kunden/Anbieter ist.
Generell fehlt mir die Abbildung des 'Workflows', also was wann und warum genau geschehen ist. Aber vielleicht habe ich mich schon zu viel mit CRM auseinandergesetzt.
Grüße
Klaus-
hallo klaus,
danke dir für deine tipps - wenn man die ganze zeit damit verbringt die datenbank zu erstellen, sieht man vor lauter bäumen den wald nicht - hast recht, natürlich ist es wichtig was mit dem objekt nun los ist (verkauft, verhandlung etc.)
danke dir!
was ist denn CRM? und was meinst du genau mit einer Workflow-Abbildung?
das ist mein erstes größeres Projekt was ich vorhabe, deswegen bin ich über jeden tipp dankbar.
ciao morpheuz
-
Hallo,
was ist denn CRM?
Customer Relationship Management == Kundebeziehungsmanagement.
und was meinst du genau mit einer Workflow-Abbildung?
Vielfach ist es notwendig nicht nur Zustände abzuspeichern, also z.B. in Deinem Falle welches Objekt ist verfügbar und wer interessiert sich dafür usw, sondern auch wie es zu diesen Zuständen gekommen ist, bzw. welche mögliche Tätigkeiten in einer bestimmte Phase der Angebostabwicklung möglich sind. z.B. kööte festgelegt sein, dass nachdem einem Kunden ein Objekt angeboten wurde, eine bstimmte Zeit auf nahcricht gewartet werden soll, und danach, falls der Kunde sich noch nicht gemeldet hat, vom System eine Nachfrage vorgeschlagen oder auch direkt ausgelöst werden soll. Also eine Abbildung des Arbeitsprozesses.
Grüße
Klaus
-
-
-
ReHallo alleine,
Objekt schreit nach Drehung um 90°...
Jede Eigenschaft ist eigentlich ein eigener Datensatz in einer Objekteigenschaftsklassentabelle, da immer noch neue Eigenschaften hinzukommen können und ein Objekt bestimmt auch mal mehrere davon haben kann.
LG
Ich
-
yo,
-
den namen und sinn der linken tabelle kann ich leider nicht sehen.
-
die letzterkontakt tabelle kann ganz wegfallen, da ja jeder kunde nur einen letzten kontakt hat und es sich somit um eine 1:1 abbildung handelt. einfach eine spalte in der kunden-tabelle hinzufügen.
-
die tabelle re_kundenobjekte braucht keinen eigenen schlüssel, kid und oid reichen vollkommen aus, um die datensätze eindeutig zu halten. ausserdem ist mir der sinn noch nicht ganz klar, was sie enthalten soll, welcher kunde was gekauft hat, bestellt hat, besitzt, bestelldatum oder kaufdatum, preise, etc.
-
die beziehung zwischen objekte und objekttypen ist falsch abgebildet, sprich der fremdschlüssel muss in die objekt-tabelle und nicht in die objekttypen tabelle.
Ilja
-
-
Cheers!
Ich habe vor eine Immobilien-Datenbank zu programmieren, dazu haben ich ein Datenbankdesign entworfen und wollte euch um Anregung, Kritik und Verbesserungsvorschläge bitten.
Ein paar kleine Anmerkungen zu den verwendeten Namen der Datenbankobjekte:
- 'kunden' statt 'kundendaten'
- 'kontakte' statt 'letzterkontakt' (s.a.u.)
- 'objekte_kunden' statt 'rel_kundenobjekte', also 1.) die zentrale Tabelle ('objekte') zuerst und 2.) den Unterstrich als Kennzeichner einer Relationentabelle nutzen (Klarstellung: So wuerde ich es machen, das bleibt natuerlich Geschmackssache.)
- 'o_ID' statt 'oID' (und weitere), also den Unterstrich auf Datenfeldebene "augenschonend" als Trenner zwischen Datenfeldpraefix und Datenfeldbezeichnung
- 'o_HatKeller' statt 'oKeller', 'o_IstMoebliert' statt 'oMoebliert', 'o_RaucherErlaubt' statt 'oRaucher' u.s.w. (Alles unter der Annahme, dass es sich um "Ja/Nein"-Felder handelt)
- 'ot_oID' statt 'oID' (in der Tabelle 'objekttypen'), 'ok_ID' statt 'iID' (Primaerschluessel der Tabelle 'objekte_kunden'/'rel_Kundenobjekte'), 'ok_oID' statt 'oID' (ebenfalls in der genannten Tabelle) u.s.w.
Vorteil: datenbankweit eindeutige Datenfeldnamen, was u.a. das JOINen erleichtert
Ein paar kleine Anmerkungen zum Design:
- eventuell die ersten Datenfelder immer 'tabelle_ID', 'tabelle_angelegt', 'tabelle_geaendert', 'tabelle_benutzername' (der Nutzer, der auf die DB zugreift), 'tabelle_besitzer' ('tabelle_b_ID' siehe auch naechsten Absatz) bezeichnen
- die "klassischen" Tabellen 'sitzungen', 'benutzer' und 'rechte' fehlen (implementieren Identifikation, Authentifikation und Autorisierung) - das _koennte_ fruehzeitig hinzugebaut werden
- darauf aufbauend koennten alle Datensaetze Besitzer erhalten (wobei sich der Besitz aendern koennte in Abhaengigkeit der letzten Aenderung (auch fuer Zwecke der Historisierung))
- weitere "Nachschlagtabellen" da, wo anscheinend auf weitere Entitaeten verwiesen wird: 'o_Heizungsart', 'o_Objektzustand', 'k_kundentyp' und weitere
- 'kontakte', weil in der genannten Tabelle vermutlich alle Kontakte gespeichert werden sollen? (Sonst waere die Existenzberechtigung der genannten Tabelle unklar)
- statt der Tabellen 'dokumente' und 'objektbilder' nur eine Tabelle 'dateien' nutzen?
Gruss,
Lude--
"Was Du heute kannst besorgen, das verschiebe nie auf morgen."-
hallo lude!
danke für die ausführliche erklärung - werde die tabelle dementsprechend verändern!
ciao morpheuz