Datenbankdiskussionsfrage: Oeffnungszeiten

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/datenbankdiskussionsfrage_oeffnungszeiten_144146/page_1 - zur Vollversion wechseln!

Rektal schrieb am 15.06.2005 um 09:59

Hi,

ich wuerde gerne eine Frage in den Raum stellen betreffen Speicherung der Daten von Oeffnungszeiten, zu denen ich derzeit zwei Ansätze sehe:

1. Ansatz: in Tabelle Oeffnungszeit steht fk von Filiale, gleiche Oeffnungszeiten wurden nicht doppelt angelegt werden

Code:

+---------+   +----------------+   +-------------+
|Filiale  |   |Verknuepfung    |   |Oeffnungszeit|
+---------+   +----------------+   +-------------+
|id (prim)|   |filiale.id      |   |id (prim)    |
|...      |   |oeffnungszeit.id|   |...          |
+---------+   +----------------+   +-------------+

2. Ansatz: Zwischentabelle, gleiche Oeffnungszeiten werden doppelt angelegt

Code:

+---------+   +---------------+
|Filiale  |   |Oeffnungszeit  |
+---------+   +---------------+
|id (prim)|   |id (prim)      |
|...      |   |filiale.id (fk)|
|...      |   |...            |
+---------+   +---------------+

Bei Ansatz eins habe ich keine doppelte Speicherung der eigentlichen Daten, beim zweiten Ansatz schon, brauch aber keinen zwischen Table, die Statements sind einfacher.

Die Datenbank ist MySql. Die Frage geht hinsichtlich Performance. Filialen wird es ca. 20000 geben, Oeffnungszeiten gibt es durchschnittlich 5 Eingtraege, waeren als ca. 100000 bei Ansatz 2, aber nur ca. 2000 bei Ansatz 1.

Die Zahlen weiss ich weil es ein Modell _aehnlich_ Ansatz 1, nur noch ein Eck komplexer, schon gibt.

derelict schrieb am 15.06.2005 um 10:09

Geringe Redundanz ist auf jeden Fall vorzuziehen! Der Performancegedanke sollte mal aussen vor bleiben, und durch Views oder Applikationsseitiges Caching gelöst werden.

Crash Override schrieb am 15.06.2005 um 10:25

Ich würde auf jeden Fall die erste Variante wählen weil die Laufzeit ansonsten doch sehr stark beeinträchtigt wird. zum Lesen kann man ja Views anlegen aber das Speichern ist komplexer. Es muss bei jeder Änderung der Öffnungszeit die tabelle durchsucht werden nach einem passenden rintrag und ggf. ein neuer erstellt werden.

Rektal schrieb am 15.06.2005 um 10:52

Mir ist nicht bekannt das MySql Views bietet. Performance ist ein Problem. Zumindest in der alten Applikation, da waren die Dinge aber noch komplexer.

Ich denke auch dass Datenredundanz hier zu bevorzugen ist. Dass Writes teurer sind ist Ok.

AoD schrieb am 15.06.2005 um 10:57

[x] 3. Ansatz
Ich würde die Daten direkt bei der Filiale speichern, also keinen Foreign Key sondern Text, Zahl, wwi.
Dann würd ich noch eine Tabelle Oeffnungszeiten machen, wo die erlaubten Werte drinnen stehen (zB 5 Zeilen). Diese Tabelle brauchst eigentlich nur fürs Frontend, damit der Benutzer eine Liste auswählbarer Werte hat.
Der Ansatz ist ähnlich deinem 1., bis auf den Unterschied dass du keine Verknüpfung hast, dir also ein join sparst.

@Rektal
im aktuellen production tree nicht, aber in 5.1 werden views kommen oder gibt es sie bereits, kA wie weit sie damit schon sind.

gerhardtt schrieb am 15.06.2005 um 11:12

mhm. ich glaub man braucht mehr infos über die benutzung um eine antwort zu geben. wie schaun die abfragen und deren häufigkeit aus?

lg

derelict schrieb am 15.06.2005 um 11:14

Zitat von Rektal
Mir ist nicht bekannt das MySql Views bietet. Performance ist ein Problem. Zumindest in der alten Applikation, da waren die Dinge aber noch komplexer.

Ich denke auch dass Datenredundanz hier zu bevorzugen ist. Dass Writes teurer sind ist Ok.

Dann würde ich die View "emulieren", oder auf ein anderes DBMS gehen. Redundanz: gut, es bringt Performance, nur die Probleme die man sich dann damit schleichend einhandelt sind dann doch eher massiv.
Also wenn Redundanz, dann in form einer temp-caching-table aber nicht als teil der Datenstruktur.