Datenbankdesign für Reisen

Hallo,

ich soll für nen Kumpel eine Datenbank erstellen in der an die 4 bis 5 Tausend Reisen rein sollen.

Folgendes habe ich mir überlegt.

Table: Kontinent

kID | kTitle

Table: Länder

lID | lTitle | kID

Table: Reisekategorien

rkID | rkTitle | rkParent


Table: Reisen

rID | rTitle | rPic | rInfo | rVerlauf | rLeistungen | rSonstiges | rData | rSaison

Table: Kategorien (einer Reise)

ID | rkID | rID

Table: Länder (einer Reise)

ID | lID | rID

Table: Reisetermine_preise

tID | tStart | tEnde | tTaeglich | tPreis | rID

Die Frage ist nur, bzw macht er sich sorgen wie schnelle die Abfragen ablaufen würden bei so einer großen Datenmenge (insgesamt mehr als 40.000 Datensätze)

Eigentlich kann man die Datenbank doch nicht noch mehr kürzen als ich getan habe!? Denn die jetzige ist ne Katastrophe man mussdie Reisen alles im HTML Dokument speichern und hochladen und kann nu den Pfad zur Datei in der DB speichern.

Also dann übt mal Kritik

EDIT: Fals ihr noch Infos benötigt gebt bescheit

[fab]

Warum ist denn "kürzen" dein Ziel? Der Aufbau sieht erstmal gut aus, schön normalisiert. 40000 Datensätze sind kein Problem, wenn die Abfragen performant geschrieben und die Tabellen entsprechend indiziert sind. Am Aufbau an sich musst du da nichts mehr optimieren.

Edit: was mir gerade nur einfällt. Denke immer an Sonderfälle, was für einen Kontinent willst du z.b. für Türkei und Russland eintragen?

[22hase]

Warum ist denn "kürzen" dein Ziel? Der Aufbau sieht erstmal gut aus, schön normalisiert. 40000 Datensätze sind kein Problem, wenn die Abfragen performant geschrieben und die Tabellen entsprechend indiziert sind. Am Aufbau an sich musst du da nichts mehr optimieren.

Reicht es denn nicht wenn die Primärschlüssel indizert sind?

Wie meinste das: Warum ist denn "kürzen" dein Ziel?

EDIT: Entweder zweimal eintragen oder nur Asien bei Türkei zum Beispiel.

EIDT 2: Was mir auch grad einfällt was ist mit Polaregionen (Antarktis) da gibts keine Länder soweit ich weiß ^^

[fab]

Reicht es denn nicht wenn die Primärschlüssel indizert sind?

Die Fremdschlüssel sollten es schon auch sein, weiteres hängt von deinen Abfragen ab.

Wie meinste das: Warum ist denn "kürzen" dein Ziel?

Du schrobst "Eigentlich kann man die Datenbank doch nicht noch mehr kürzen als ich getan habe!? " - das klingt als wäre "kurz" dein Qualitätskriterium.

EDIT: Entweder zweimal eintragen oder nur Asien bei Türkei zum Beispiel.

EIDT 2: Was mir auch grad einfällt was ist mit Polaregionen (Antarktis) da gibts keine Länder soweit ich weiß ^^

Wenn du wirklich Reisen in die Antarktis anbietest, dann ist vielleicht "Kontinent: Antarktis, Land: Antarktis" eine Lösung, mit der man leben kann

[mimomamu]

Reicht es denn nicht wenn die Primärschlüssel indizert sind?

Grundsätzlich kannst du jede Datenbankabfrage unabhängig von vergebenen Indizes durchführen. Soweit ich weiß werden Indizes im SQL-Standard auch überhaupt nicht erwähnt, weil sie zur physischen Repräsentation der Daten gehören, SQL aber lediglich die logische Repräsentation der Daten standardisiert.

Ein Index bringt Geschwindigkeitsvorteile wenn die Spalte ein Kriterium für die Auswahl von Datensätzen ist. Ziel ist es, bei einer Bedingung

WHERE Foo = 'Bar'

nicht alle Datensätze durchsuchen zu müssen.

Kandidaten für Indizes sind Fremdschlüssel (da sie in der ON-Bedingung von JOIN-Klauseln auftauchen) und Spalten die in WHERE-Bedingungen auftauchen.

Den Performancegewinn in SELECT-Abfragen durch Indizes erkauft man sich durch einen Performanceverlust beim Einfügen von Datensätze (jeder Index der betroffenen Tabellen muss aktualisiert werden).

EIDT 2: Was mir auch grad einfällt was ist mit Polaregionen (Antarktis) da gibts keine Länder soweit ich weiß ^^

In der Arktis gibt es kein Festland. Die Antarktis kannst du als einziges Land auf dem gleichnamigen Kontinent modellieren (außer es kommen z.B. unterschiedliche Visabstimmungen zum Tragen, je nach dem wer den Teil der Antarktis beansprucht. Wikipedia: Politischer Status der Antarktis)

[22hase]

Ne Kurz ist nicht mein Qualitätskriterium

Ein Index bringt Geschwindigkeitsvorteile wenn die Spalte ein Kriterium für die Auswahl von Datensätzen ist. Ziel ist es, bei einer Bedingung Code:
WHERE Foo = 'Bar'
nicht alle Datensätze durchsuchen zu müssen.

Hab ich das so richtig verstanden:

Sagen wir es gibt in der Table: Länder einer Reise 500 Datensätze

200 mit der rID 2 und 300 mit der rID 3

Angenommen 2 stehe für Deutschland somit durchsucht die Db nicht 500 sondern bloß 300 ?



EDIT: hab auch mal irgendwo gelesen das man falsch indizieren kann, und somit der schuß nach hinten losgeht, aber kein plan ob dies tatsachen entspricht

[mimomamu]

Ich glaube du hast es richtig verstanden. Angenommen du hast eine Bedingung WHERE rID = 3.

• Ohne Index auf rID wird in jedem der 500 Datensätze nachgeschaut, was für eine rID er hat.
• Mit Index auf rID weiß die Datenbank sofort, wo die Datensätze physisch abgelegt sind, die die rID 3 haben.

[22hase]

Ich glaube du hast es richtig verstanden. Angenommen du hast eine Bedingung WHERE rID = 3.

• Ohne Index auf rID wird in jedem der 500 Datensätze nachgeschaut, was für eine rID er hat.
• Mit Index auf rID weiß die Datenbank sofort, wo die Datensätze physisch abgelegt sind, die die rID 3 haben.

Year. Ok also auf jeden Fall in den Tabellen

Table: Länder (einer Reise)
Table: Kategorien (einer Reise)
Table: Reisetermine_preise

die rID indizieren

[nikosch]

rkTitle
lTitle

Finde ich irgendwie schwer lesbar. Solche Sachen sollte man IMHO Mit Aliasen machen.

[Chriz]

EDIT: Entweder zweimal eintragen oder nur Asien bei Türkei zum Beispiel.

Dann taucht die Türkei bei Europaangeboten nicht auf? Das ist einfach falsch und wird dir nur Probleme bereiten. Land zu Kontinent ist eine 1:n Beziehung und muss auch so modelliert sein.

[22hase]

Finde ich irgendwie schwer lesbar. Solche Sachen sollte man IMHO Mit Aliasen machen.

hast schon recht, aber ich komm damit besser klar

[nikosch]

Vielleicht solltest Du neben echten Kontinenten zusätzlich auch Gegenden wie „Osteuropa“, „Balkan“ oder „Karibik“ oder „Mittelmeerraum“ anbieten. Die 5 „Reise“kontinente sind irgendwie praxisfremd als Auswahlkriterium.

[22hase]

Vielleicht solltest Du neben echten Kontinenten zusätzlich auch Gegenden wie „Osteuropa“, „Balkan“ oder „Karibik“ oder „Mittelmeerraum“ anbieten. Die 5 „Reise“kontinente sind irgendwie praxisfremd als Auswahlkriterium.

War eh meine Absicht (Skandinavien, südliches Afrika usw.) Dies wird ich aber einfach in die Ländertablle reinschreiben

[fab]

Dann taucht die Türkei bei Europaangeboten nicht auf? Das ist einfach falsch und wird dir nur Probleme bereiten. Land zu Kontinent ist eine 1:n Beziehung und muss auch so modelliert sein.

Du meinst n:m oder gilt neuerdings "jeder Kontinent nur ein Land"?

Interessant wird es dann, wenn einzelne Ziele entsprechend korrekt eingeordnet werden sollen, bspw.:

Europa -> Türkei -> Çorlu
Asien -> Türkei -> Antalya

Dazu ein Ansatz:

Kontinent
 - kontinent_id
 - ...

Land
 - land_id
 - ...

Land_Kontinent
 - lk_id
 - land_id
 - kontinent_id

Reiseziel
 - id
 - lk_id
 - ...

[nikosch]

Dies wird ich aber einfach in die Ländertablle reinschreiben

Wo es total falsch ist.

Eigentlich mal überlegt, ob es landesübergreifende Reisen geben könnte? Vielleicht solltest Du gleich eine Art Tagging benutzen.
Reise --- 1:n --- Gegenden/Ziele/Länder