[SQL] Gleiche Parkplätze andere Parkplatz-Nummer, Redundanzen?

[mister-t]

Hallo zusammen

Also ich muss eine Datenbank erstellen, in dem es um Parkplätze geht, welche reserviert werden können.

Dabei habe ich eine Tabelle PARKPLATZ in der die Fremdschlüssel der Liegenschaft (Parkhaus) und des Parkplatz-Types zu finden ist (z.B. Parkplatz für Motorräder so breit und so lange usw.). Natürlich befindet sich auch eine Spalte Nummer, womit ich die Parkplätze Nummeriere (Parkplatz 1,2,3 usw.), doch dies ist nicht die ID.

Jetzt meine Frage, ist das nicht etwas Redundant, dann muss ich zum Beispiel bei 50 gleichen Parkplätzen jeden Parkplatz einzeln einfügen, bis 50 nummerieren und 50-mal die gleichen Fremdschlüssel vergeben. Ist das Konsistent oder nicht? Von mir aus sehe ich da keine andere Möglichkeit...

Danke schon einmal.

 

[Valeria]

Parkhaus:
id | name
1 | krankenhaus
2 | whatever

parkplatz: (schwache entität)
id | parkhaus_id | parkplatz_type
1 | 1 | 1
2 | 1 | 2
3 | 1 | 1
....
50 | 1 | 2
1 | 2 | 1
2 | 2 | 1
....
50 | 2 | 2
PRIMARY KEY (id, parkhaus_id)

parkplatz_type
id | Beschreibung
1 | Motorrad
2 | Auto

 

[mister-t]

Okey danke, das ist mir jetzt neu, zwei Spalten als Primary Key, dann bestehen auch 2 Fremdschlüssel von diesem Primary Key, oder wird das dann in einen gepackt?

 

[Valeria]

Ich verstehe die Frage nicht richtig, du musst schon bei einer anderen Tabelle 2 Fremdschlüssel erstellen und auch beim joinen undso beide vergleichen.

Testtabelle:
id | iwas | parkplatz_id | parkhaus_id
1 | "lala" | 2 | 1
2 | "blubb" | 5 | 2
FOREIGN KEY (parkplatz_id, parkhaus_id) REFERENCES Parkplatz(id, parkhaus_id)

SELECT *
FROM Testtabelle t JOIN Parkplatz p ON (t.parkplatz_id = p.id AND t.parkhaus_id = p.parkhaus_id)

 

[mister-t]

Also wenn ich dann zum Beispiel der Parkplatz mit ID so und so ist von dieser Person reserviert, dann brauche ich ja den Fremdschlüssel des Primary Keys, das wäre dann einfach REFERENCES ON PARKPLATZ(id, parkhaus_id), wenn ich das richtig verstehe..?

 

[Valeria]

Du brauchst beide, aber fürs Reservieren wird mal wohl die Personen_id im Parkplatz speichern, immerhin kann ja sicher eine Person mehere Parkplätze reservieren und nicht umgekehrt.

Edit: siehe oben

 

[mister-t]

Gibt ne Zwischentabelle (Reservation), UserID und die ParkplatzID, da ja ein Parkplatz nicht für ein Leben lang besetzt ist

 

[Valeria]

Naja man kanns ja auch überschreiben die Reservierungen, aber dann hat man keine Logs^^

 

[mister-t]

Ja aber für die History ist es besser mit Tabelle Reservierung Also DANKE!!!

 

[mister-t]

Ich habe noch einmal eine Frage...

...es geht darum, dass zum Beispiel das Mieten eines Parkplatzes pro Tag teurer (wenn man den Tages-Preis * Anzahl Monatstage rechnen würde) ist als pro Monat, dazu gibt es auch eine maximale Reservationsperiode.

Würde das Folgende sinn machen?
- In Tabelle Parkplatz eine maximale Reservationsperiode-Spalte
- In Tabelle Parkplatz einen FK, welcher zu einer Kosten-Tabelle führt (Z.B, #id_kosten, tagespreis, monatspreis, jahrespreis)

Aber da habe ich noch ein Problem, zum Beispiel sagt man bei der Reservation man wolle den Parkplatz einen Tag mieten und jemand anderes will ihn ein 1 Monat mieten, wie soll ich das dann unterscheiden (nur eine Spalte "Dauer" in der Reservations-Tabelle würde ja nicht definieren, ob es jetzt 1 Tag, Monat oder Jahr ist, da ich wohl nur ein 1 reinschreiben würde...)?

Müsste da ich mit einem weiteren FK arbeiten? Zum Beispiel eine Tabelle Periodenart (z.B. ID 1 ist Tag, ID 2 ist Monat) und dann in der Reservation für dauer eine 1 und für Tag den FK 1 (d.h. Spalte FK von Periodenart und dauer in Reservation). Wäre dies unnötig oder gäbe es eine besser Lösung?

Ich hoffe es ist verständlich und ihr könnt mir rasch helfen, da es morgen testweise gebraucht wird...

 

[Daaron]

Aber da habe ich noch ein Problem, zum Beispiel sagt man bei der Reservation man wolle den Parkplatz einen Tag mieten und jemand anderes will ihn ein 1 Monat mieten, wie soll ich das dann unterscheiden (nur eine Spalte "Dauer" in der Reservations-Tabelle würde ja nicht definieren, ob es jetzt 1 Tag, Monat oder Jahr ist, da ich wohl nur ein 1 reinschreiben würde...)?

Was hindert dich, eine genormte Zeit da rein zu schreiben, vielleicht sogar einfach in Sekunden?

 

[AlbertLast]

Oder Start und Endzeitpunkt rein schreiben.

 

[mister-t]

Oke danke, aber dann müsste man mit der Programmiersprache herausfinden ob es eine Tages-, Wochen- oder Monatsmiete ist, da die Preise unterschiedliche sind...

Also dann ist meines keine gute Lösung?

 

[Daaron]

Wenn es eine feste Korrelation zwischen Mietdauer und Preis gibt, dann wäre ein FK angebracht.

 

[mister-t]

Hier habe ich mal das ERM:

 

[AlbertLast]

Das erm finde ich interessant,
ich will mal ein mögliches feature von postgresql hier anmerken was dir helfen könnte.

pg kann rangetype : http://www.postgresql.org/docs/9.4/static/rangetypes.html
platt gesagt kannst in einem datenfeld ein anfang und endpunkt darstellen z.b. 12:00 24.01.2015 - 14:00 24.01.2015
daraus könnte man nartülich die dauer automatisch bestimmen lassen.

ABER wo der große vorteil ist, dü könntest diesen datentyp in der tabel Reservation, anstatt dauer nehmen (start punkt fehlt dir)
und dann ein unique index auf parkplatz_id und range machen,
damit wäre es nicht möglich ein reservierten parkplatz zum zeitpunkt x noch mal durch ein anderen reservieren zu lassen,
dies unterbindet der unique index dann!

PS. Es gibt auch ein paar interessante operatoren die pg für rangetype anbietet

 

[mister-t]

Vielen Dank!

Ich werde mir das dann noch einmal genauer anschauen, also da habe ich schon mal neues dazu gelernt!
Da aber das Projekt nicht mehr so wichtig sein wird (weil meine Gruppe zu faul war ausser ich;war ein Schulprojekt in der Lehre), habe ich jetzt mehr Zeit dafür.

Gleichwohl werde ich noch das Projekt beenden, damit ich mein Wissen in Datenbanken erweitern kann.