MySQL: Frage des Designs

[Tommy57]

Hallo,

wir möchten aktuell eine Datenbank aufbauen, mit der wir im Prinzip Fahrten wir bei http://www.mitfahrgelegenheiten.de speichern und durchsuchen können.

Jede Fahrt besteht immer aus einer Startadresse und einer Zieladresse. Es gab in unserer Gruppe zwei Vorschläge und ich wollte daher mal hier nach eurer Meinung fragen:

1. Vorschlag

Fahrt
fahrt_id, user, starttime
1, 'Max', 2014-12-04 20:00:00
2, 'Wolfram', 2014-12-06 14:30:00

Assoziationstabelle (Fahrt/Adressen)
fahrt_id, address_id, type (start = 1 / ziel = 2)
1, 2, 1
1, 3, 2
2, 4, 1
2, 2, 2

Adressen
address_id, street, number, zip_code, city, lat, lang
1, Muserstraße, 17, 40597, Düsseldorf...
2, Musterstraße, 17, 40597, Düsseldorf...
3, Zielstraße, 23, 40229, Düsseldorf...
4, Letzter Weg, 119, 40591, Düsseldorf...

+ Keine redundanten Adressen, jede Adresse kann von jedem beliebig oft verwendet werden
- Adressen dürfen nicht editiert werden, es muss statt dessen ein INSERT gemacht werden
- Unzählige Datenleichen


2. Vorschlag

Fahrt
fahrt_id, user, starttime
1, 'Max', 2014-12-04 20:00:00
2, 'Wolfram', 2014-12-06 14:30:00

Stationen
station_id, fahrt_id, street, number, zip_code, city, lat, lang, type (start = 1 / ziel = 2)
1, 1, Musterstraße, 17, 40597, Düsseldorf..., 1
2, 1, Zielstraße, 23, 40229, Düsseldorf..., 2
3, 2, Letzter Weg, 119, 40591, Düsseldorf..., 1
4, 2, Musterstraße, 17, 40597, Düsseldorf..., 2

+ Stationen können vom User direkt editiert werden
- Redundante Daten


Würde mich über eure Meinung freuen.

Gruß, Tommy

Adressen

 

[sheel]

Hi

vorausgesetzt, die Adressen werden rein händisch eingegeben (ohne irgendeine korrektierende Unterstützung
wie Google Maps) würd ich eig. Variante 2 nehmen, mti dem Hintergedanken, dass man auch für die selbe
Adresse verschiedene Schreibweisen haben kann (vor allem wenn es um etwas Bekanntes, geht wo viele hin
wollen) und der Gewinn durch wiedergefundene Adressen vermutlich nicht nennenswert sein wird.

 

[Tommy57]

Danke für die schnelle Antwort sheel.

Also vermutlich würden wir jede Adresse bei Google abgefragen, um Längengrad und Breitengrad zu ermitteln.

Ich selber tendiere zu Variante 2, aber mir fehlen ein wenig die Argumente, um das in der Gruppe durch zu kriegen. Ich lasse mich aber auch gerne eines besseren belehren. Aktuell stehen wir alle ohne gute Argumente da.

 

[BaseBallBatBoy]

- Adressen dürfen nicht editiert werden, es muss statt dessen ein INSERT gemacht werden
- Unzählige Datenleichen

Warum? Ich verstehe diese beiden Kontrapunkte nicht wirklich.

Wenn ich dich wäre, würde ich mir mal die Frage stellen, welche Antworten muss mir die DB liefern können? Welche Daten brauche ich um alle meine Fragen zu beantworten? Dann stell dir mal die Frage welche Entitäten es geben könnte. Entitäten lassen sich Typischerweise in eine dieser vier Kategorien zuordnen: Personen, Dinge, Events und Orte. Danach überleg dir welche Relationen gibt es zwischen deinen Entitäten. Am Ende wirst du ein ERM haben (http://de.wikipedia.org/wiki/Entity-Relationship-Modell). Bis hier hin hast du noch keine einzige Zeile SQL geschrieben.

Ohne mir jetzt alle möglichen Use Cases durchzudenken, sehe ich auf einen ersten Blick 3 Kernentitäten.

Der Zentrale ist die "Fahrt" die Angeboten wird. Hat so Zeugs wie ID, ID des "Anbieters/Fahrers", Startort ID, Zielort ID (ich sehe hier im Gegensatz zu deiner Variante 1 keinen Grund dazu 2 Zeilen zu haben, warum hast du 2 vorgeschlagen?), Start Zeit, (geschätzte) Ankunftszeit (wenn du das denn brauchst)

Dann der (Start/Ziel-)Ort. Strasse, PLZ, Ort, Lat, Long, etc. Wenn du von Start und Ziel immer lat/long hast, kannst du dann auch so lustige Sachen machen wie die Distanz berechnen. Hier solltest du dir auch die Frage stellen, gibt es nur Fahrten im Inland oder soll es auch möglich sein im Adressen im Ausland anzugeben? Je nachdem hat dies einen Einfluss auf das Datenmodell.

Und dann natürlich der "Anbieter/Fahrer". Name, Vorname, Adresse, etc.

Dann musst du dich auch Fragen ob du die "Teilnehmer/Mitfahrer" auch brauchst. Ob du z.B. wissen musst dass bei Fahrt A niemand mitgefahren ist aber bei Fahrt B total 3 mitgefahren sind.

Und da es Wahrscheinlich eine Webseite sein soll, den ganzen technischen Kram mit Login/PW, etc. auch irgendwo ablegen.

Bezüglich "Datenleichen" kannst du ja wenn du dann mal im Betrieb bist, Periodisch immer mal wieder hingehen und altes Zeugs Archivieren/Löschen wenn du es nicht mehr haben willst. Eine Fahrt die vor einem halben Jahr stattgefunden hat ist evtl. nicht mehr interessant für dich.

 

[sheel]

@Tommy: Um direkt auf Google Maps einzugehen: Wie wärs, die Adressen gar nicht
lokal zu speichern, sondern immer nur die anfänglich Koordinaten. Bei Bedarf sich dann die Adresse
wieder von Google liefern lassen

Falls man keine Zwischenstationen haben will kann die zweite Tabelle ganz weg, und einfach zwei Spalten
Anfang/Ende in die Fahrtentabelle. Natürlich können Korrdinaten nach wie vor doppelt vorkommen,
aber verglichen mit den vollen Adressen ist der Overhead zu vernachlässigen.

 

[Tommy57]

Danke für die Antworten.

Ja, es ist eine Webseite, die später bei Eingabe einer Startadresse, einem Umkreis (zb 10km), einem Datum und einem Zielort, alle Fahrten anzeigt, die in Frage kommen. Deswegen auch Längengrad und Breitengrad, um den Umkreis bestimmen zu können, was wir beim Erstellen der Fahrt von Google Maps holen würden.

Und in der Tabelle Fahrten sind zwei Zeilen, weil ich zwei unterschiedliche Fahrten zeigen wollte.


Es geht im wesentlichen nur darum, ob wir zwei Tabellen (Station / Adresse) oder eine Tabelle (nur Station) verwenden. Es gibt bei jeder Fahrt nur zwei Stationen, start und ziel.

Bei der Variante mit zwei Tabellen hätten wir keine redundanten Adressen, weil es eine extra Tabelle für die paar hundert oder tausend Adressen gäbe. Es könnten und werden viele Stationen auf eine Adresse verweisen. Wenn ein User zum Beispiel seine Startadresse editiert, kann kein UPDATE auf die Datenbank ausgeführt werden, statt dessen muss eine neue Adresse angelegt werden und die Station muss dann auf diese neue Adresse zeigen. Die alte Adresse dürfte dann auch nicht einfach gelöscht werden, weil es sein könnte, dass eine andere Station diese Adresse noch verwendet.

Bei der Variante mit einer Tabelle würden wir die Adresse in der Station abspeichern, wodurch es zu redundanten Daten kommt, wenn eine Adresse öfters angefahren wird. Dennoch tendiere ich zur Variante mit einer Tabelle, da ich große Vorteile in der Handhabung und somit auch für die Programmierung sehe. Auch FOREIGN-KEYS wären dann möglich.

Also ich finde der Overhead durch die Adressen ist vernachlässigbar und die Redundanz auch. Habt ihr vielleicht noch eine Idee, warum eine Variante besser oder schlechter ist? Bisher ist das alles nur sehr vage.