Oeffnungszeiten abbilden

Hallo NG,

ich hab mal eine Frage, ich habe zwei Lösungsansätze und würde gern wissen,
wo ihr einen Vorteil seht und wo einen Nachteil:

Lösung 1:
Laden und Öffnungszeit werden in verschiedenen Tabellen gehalten und über
eine 3te Tabelle verknüpft. Vorteil aus meiner Sicht, man spart ein bißchen
Plattenplatz (Redundanz) und die Abfragen sind eventuell flexibler.
Nachteil, die Abfragen werden dafür etwas komplexer.

+-----------+
| tblLaeden |
+-----------+
| LadenID |
| .. |
+-----------+

+--------------------+
| tblOeffnungszeiten |
+--------------------+
| OeffnungszeitID |
| Tag |
| Start |
| Ende |
+--------------------+

+--------------------------+
| tblLaedenOeffnungszeiten |
+--------------------------+
| LadenID |
| OeffnungszeitID |
+--------------------------+


Lösung 2:
Es gibt zwei Tabellen jeder Laden hat seine speziellen Öffnungszeiten.
Vorteil: die Abfragen werden einfacher. Nachteil: wahrscheinlich ziemlich
viel Redundanz.

+-----------+
| tblLaeden |
+-----------+
| LadenID |
| .. |
+-----------+

+--------------------+
| tblOeffnungszeiten |
+--------------------+
| OeffnungszeitID |
| LadenID |
| Tag |
| Start |
| Ende |
+--------------------+

Was denkt ihr, was sollte man vorziehen. Oder gibt es eventuell noch eine
deutlich geeignetere Lösung? Ich kann zum Beispiel keine Dinge wie jede
zweite Woche oder am ersten Samstag im Monat mit dieser Struktur darstellen.

Danke
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Oeffnungszeiten abbilden

Johannes Mueller wrote:
> Lösung 1:
> Laden und Öffnungszeit werden in verschiedenen Tabellen gehalten und über
> eine 3te Tabelle verknüpft. Vorteil aus meiner Sicht, man spart ein bißchen
> Plattenplatz (Redundanz) und die Abfragen sind eventuell flexibler.
> Nachteil, die Abfragen werden dafür etwas komplexer.
>
> +-----------+
> | tblLaeden |
> +-----------+
> | LadenID |
> | .. |
> +-----------+
>
> +--------------------+
> | tblOeffnungszeiten |
> +--------------------+
> | OeffnungszeitID |
> | Tag |
> | Start |
> | Ende |
> +--------------------+
>
> +--------------------------+
> | tblLaedenOeffnungszeiten |
> +--------------------------+
> | LadenID |
> | OeffnungszeitID |
> +--------------------------+
>
>
> Lösung 2:
> Es gibt zwei Tabellen jeder Laden hat seine speziellen Öffnungszeiten.
> Vorteil: die Abfragen werden einfacher. Nachteil: wahrscheinlich ziemlich
> viel Redundanz.
>
> +-----------+
> | tblLaeden |
> +-----------+
> | LadenID |
> | .. |
> +-----------+
>
> +--------------------+
> | tblOeffnungszeiten |
> +--------------------+
> | OeffnungszeitID |
> | LadenID |
> | Tag |
> | Start |
> | Ende |
> +--------------------+
>
> Was denkt ihr, was sollte man vorziehen. Oder gibt es eventuell noch eine
> deutlich geeignetere Lösung? Ich kann zum Beispiel keine Dinge wie jede
> zweite Woche oder am ersten Samstag im Monat mit dieser Struktur darstellen.

Lösung 1 kann alles was Lösung 2 auch kann. Allerdings ist auch das
nicht normalisiert. Bei Lösung 2 kannst Du mehrere Läden nicht
zusammenfassen. Bei Lösung 1 dagegen kann es zu einer komischen
Vermengung verschiedenen Öffnungszeitenmodelle bzw. -Systeme kommen.

Statt Öffnungszeiten würde ich das "Öffungszeitensystem" verwenden und
bei Laden auf dieses System verweisen. Dann würde ich zu jedem System
jeweils die Liste der Öffnungszeiten in einer dritten Tabelle ablegen.

Grundlegend ist aber auch die Frage wie genau muss das Datenmodell die
Öffnungszeiten wiedergeben? Dieser Bedarf kann sehr unterschiedlich
sein. Oft ist es sehr schwer aus korrekt gespeicherten Zeitangaben einen
guten Text zu erstellen. Da kann es sinnvoll die Zeiten zusätzlich für
Kunden als Klartext anzugeben. Diese Redundanz sollte aber wohl überlegt
und Fehlermöglichkeiten durch ergonomische Software reduziert werden.

Der Plattenplatz sollte keine Rolle spielen. Die paar Daten beanspruchen
nicht so viel Platz. Wichtiger ist bei Redundanz die Gefahr von
Inkonsistenten Daten. Das ist ja auch die Gefahr bei einem zusätzlichen
Text.

> +-----------+
> | tblLaeden |
> +-----------+
> | LadenID |
> | .. |
> +-----------+

+-------------------------+
| tblOeffnungszeitenmodel |
+-------------------------+
| OeffnungszeitmodelID |
| Text | ggf. für Menschen verfasster Klartext
+-------------------------+

> +--------------------+
> | tblOeffnungszeiten |
> +--------------------+
| OeffnungszeitmodelID
| ...
> +--------------------+

Wie die einzelnen Öffnungszeiten gespeichert werden, kann auch wieder
unterschiedlich sein. So könnten z.B. in einer vierten Tabelle die
Wochentage abgelegt werden. Dazu sollten Beispiele für Kalender als
Vorlage nützlich sein.

Außerdem kann es sinnvoll sein Zeiten für einen vorgegebenen Zeitraum
gültig sein zu lassen. Sie können sich ja auch mal ändern und es ist
dann nicht schön diese Änderung lediglich durch Ändern in Echtzeit
angeben zu können.

Heiko
--
http://portal.richler.de/ Namensportal zu Richler
http://www.richler.de/ Heiko Richler: Computer - Know How!
http://www.richler.info/ private Homepage

Re: Oeffnungszeiten abbilden

On 28 Okt., 17:44, "Johannes Mueller" wrote:
> Hallo NG,
>
> ich hab mal eine Frage, ich habe zwei Lösungsansätze und würde gern=
wissen,
> wo ihr einen Vorteil seht und wo einen Nachteil:
>
> Lösung 1:
> Laden und Öffnungszeit werden in verschiedenen Tabellen gehalten und =
über
> eine 3te Tabelle verknüpft. Vorteil aus meiner Sicht, man spart ein bi=
ßchen
> Plattenplatz (Redundanz) und die Abfragen sind eventuell flexibler.
> Nachteil, die Abfragen werden dafür etwas komplexer.
>
> +-----------+
> | tblLaeden |
> +-----------+
> | LadenID |
> | .. |
> +-----------+
>
> +--------------------+
> | tblOeffnungszeiten |
> +--------------------+
> | OeffnungszeitID |
> | Tag |
> | Start |
> | Ende |
> +--------------------+
>
> +--------------------------+
> | tblLaedenOeffnungszeiten |
> +--------------------------+
> | LadenID |
> | OeffnungszeitID |
> +--------------------------+
>
> Lösung 2:
> Es gibt zwei Tabellen jeder Laden hat seine speziellen Öffnungszeiten.
> Vorteil: die Abfragen werden einfacher. Nachteil: wahrscheinlich ziemlich
> viel Redundanz.
>
> +-----------+
> | tblLaeden |
> +-----------+
> | LadenID |
> | .. |
> +-----------+
>
> +--------------------+
> | tblOeffnungszeiten |
> +--------------------+
> | OeffnungszeitID |
> | LadenID |
> | Tag |
> | Start |
> | Ende |
> +--------------------+
>
> Was denkt ihr, was sollte man vorziehen. Oder gibt es eventuell noch eine
> deutlich geeignetere Lösung? Ich kann zum Beispiel keine Dinge wie jede
> zweite Woche oder am ersten Samstag im Monat mit dieser Struktur darstell=
en.
>
> Danke
> Johannes
>
> --
> Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.


hallo
ist wohl kein mysql thema sondern eher ein allgemeines designproblem.
ich hab da speziell keine praktische erfahrung, aber folgende
überlegungen:

der erste vorschlag von dir enthält nicht grundsätzlich weniger
redundanz, das hängt eher von der grundstruktur des problems ab: jahre
individuell festlegen kann.
wenn jeder laden seine öffnunfszeiten unabhängig von den anderen
festlegt, dann enthält der erste vorschlag eher mehr überflüssiges
zeug und ist ineffizient, und der zweite vorschlag angemessen. wenn
sich die läden in bestimmte gruppen unterteilen lassen, und jede
gruppe eine bestimmte ladenschlusszeit hat, dann ist der erste
vorschlag vermutlich der angemessene.

das du jeden 2. samstag im monat oder ähnliches nicht mit diesen
struktur darstellen kannst, sehe ich eigentlich nicht so. das ist nur
der fall, wenn du das attribut "tag" auf mo,di,mi,...,so einschränkst.
du kannst ja "tag" erweitern um die werte "1samstag im monat" usw.
auch ein 2-wochenrythmus lässt sich so darstellen, "tag" hat dann die
werte mo1,di1,...,so1,mo2,di2,...,so2

man könnte für jeden laden und jeden tag (z.b. bis ins jahr 2100)
einen kalender mit den öffnungszeiten erstellen. das erscheint dir
wahrscheinlich wieder mit redundanz behaftet (mir auch) . wenn jeder
laden seine öffnungszeiten für jeden tag der nächsten 100 jahre
individuell festlegen kann, ist es aber nicht redundant.

vermutlich ist so ein individueller kalender nicht überflüssig.
vielleicht kann man jedem laden eine liste von kalendern zuordnen.
will man die öffnunfszeit für einen bestimmten tag ermitteln, geht man
die kalender der liste durch, bis man einen kalender findet in dem der
tag enthalten ist.im ersten kalender für einen laden sind eindeutige
tage mit den öffnungszeiten es ladens eingetragen, z.b. 25.3.2008
9:00-12:00. an diesem tag hat der laden inventur und deshalb
nachmittags geschlossen. dies gilt nur für diesen laden.
im zweiten kalender sind alle tage im jahresrythmus vermerkt, für die
es spezielle öffnungszeiten gibt, z.b 24.Dez (wenn werktag),
23.Dezember (wenn samstag) ; im dritten kalender alle tage im
monatsrythmus, z.b. jeder 1. samstag im monat, im 4. kalender im
wochenrythmus (jeden 2. mittwoch ) im 5.kalender werden alle tage
abgefangen (mo-so)

das ganze muss noch etwas weiterentwickelt werden.

mfg günter

Re: Oeffnungszeiten abbilden

guenter.nowak@gmx.at wrote:

> hallo
> ist wohl kein mysql thema sondern eher ein allgemeines designproblem.
> ich hab da speziell keine praktische erfahrung, aber folgende
> überlegungen:
>
> der erste vorschlag von dir enthält nicht grundsätzlich weniger
> redundanz, das hängt eher von der grundstruktur des problems ab: jahre
> individuell festlegen kann.
> wenn jeder laden seine öffnunfszeiten unabhängig von den anderen
> festlegt, dann enthält der erste vorschlag eher mehr überflüssiges
> zeug und ist ineffizient, und der zweite vorschlag angemessen. wenn
> sich die läden in bestimmte gruppen unterteilen lassen, und jede
> gruppe eine bestimmte ladenschlusszeit hat, dann ist der erste
> vorschlag vermutlich der angemessene.

Irgendwie hätte ich es eher andersherum interpretiert. Denn mit der ersten
Lösung kann man alle handeltreibenden Unternehmen mit vielleicht 20
verschiedenen Einträgen erschlagen. Das heisst Öffnungszeiten hätte
vielleicht 100 verschiedene Möglichkeiten.

Vorwiegend wahrscheinlich 900 - 2000 und 900-1300 und 1330-2000 etc. Da kann
man ziemlich viele Varianten erwischen. Und dann braucht man diese nur noch
mit den einzelnen Läden verknüpfen. Das heisst 1000e Firmen, die von
900-2000 Uhr offen haben teilen sich eine Öffnungszeit.

Die zweite Lösung jedoch muss den Tag, die Start und Endzeit für jeden
Eintrag wiederum mitführen und hat dadurch mehr Overhead.

Der Sinn soll später sein einen offenen Laden zu finden, das geht auf
jedenfall mit beiden Lösungen, wobei die erste meiner Meinung nach eben
etwas flexibler ist.

> das du jeden 2. samstag im monat oder ähnliches nicht mit diesen
> struktur darstellen kannst, sehe ich eigentlich nicht so. das ist nur
> der fall, wenn du das attribut "tag" auf mo,di,mi,...,so einschränkst.
> du kannst ja "tag" erweitern um die werte "1samstag im monat" usw.
> auch ein 2-wochenrythmus lässt sich so darstellen, "tag" hat dann die
> werte mo1,di1,...,so1,mo2,di2,...,so2

Ja, das scheint eine sinnvolle Ergänzung zu sein. Wobei ich eine so
generelle Lösung eventuell nicht implementieren werde - wobei ich damit auf
die Nase fallen könnte. Die Eingabe durch die Nutzer könnte dann nämlich
sehr unkomfortabel werden.

> man könnte für jeden laden und jeden tag (z.b. bis ins jahr 2100)
> einen kalender mit den öffnungszeiten erstellen. das erscheint dir
> wahrscheinlich wieder mit redundanz behaftet (mir auch) . wenn jeder
> laden seine öffnungszeiten für jeden tag der nächsten 100 jahre
> individuell festlegen kann, ist es aber nicht redundant.

Mag sein, dass es vom Sinn her nicht redundant ist, aber das ist meiner
Meinung nach bei Öffnungszeiten unnötig, da diese zu 95% regelbasiert sind.

> vermutlich ist so ein individueller kalender nicht überflüssig.
> vielleicht kann man jedem laden eine liste von kalendern zuordnen.
> will man die öffnunfszeit für einen bestimmten tag ermitteln, geht man
> die kalender der liste durch, bis man einen kalender findet in dem der
> tag enthalten ist.im ersten kalender für einen laden sind eindeutige
> tage mit den öffnungszeiten es ladens eingetragen, z.b. 25.3.2008
> 9:00-12:00. an diesem tag hat der laden inventur und deshalb
> nachmittags geschlossen. dies gilt nur für diesen laden.
> im zweiten kalender sind alle tage im jahresrythmus vermerkt, für die
> es spezielle öffnungszeiten gibt, z.b 24.Dez (wenn werktag),
> 23.Dezember (wenn samstag) ; im dritten kalender alle tage im
> monatsrythmus, z.b. jeder 1. samstag im monat, im 4. kalender im
> wochenrythmus (jeden 2. mittwoch ) im 5.kalender werden alle tage
> abgefangen (mo-so)
>
> das ganze muss noch etwas weiterentwickelt werden.

Das ist jetzt so geschrieben, dass ich es gar nicht mehr nachvollziehen
kann - aber danke schonmal für deine Antwort.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Oeffnungszeiten abbilden

Heiko Richler wrote:

> Außerdem kann es sinnvoll sein Zeiten für einen vorgegebenen Zeitraum
> gültig sein zu lassen. Sie können sich ja auch mal ändern und es ist
> dann nicht schön diese Änderung lediglich durch Ändern in Echtzeit
> angeben zu können.

Das scheint mir logisch zu sein. Sollte man wohl irgendwie auch verwursten.
Das mit den Öffnungszeitenmodellen muss ich mir nochmal durchlesen, auf den
ersten Lesedurchgang hab ich das nicht ganz nachvollziehen können.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Oeffnungszeiten abbilden

Johannes Mueller schrieb:

> ich hab mal eine Frage, ich habe zwei Lösungsansätze

Ich habe auch eine Frage: Für welches Problem?

Gruß. Claus

Re: Oeffnungszeiten abbilden

Claus Reibenstein wrote:
> Johannes Mueller schrieb:
>
>> ich hab mal eine Frage, ich habe zwei Lösungsansätze
>
> Ich habe auch eine Frage: Für welches Problem?

Möglichst effizient Öffnungszeiten zu speichern. So dass man jederzeit
checken kann, welcher Laden momentan offen ist, oder zu einer bestimmten
Zeit sein wird. Da dies beide Lösungen können, ist die Frage halt, welcher
der beiden man den Vorzug geben sollte und was man dabei beachten muss.

Da ich sicher nicht der erste bin, der damit schonmal in Berührung gekommen
ist habe ich mir ein paar sachdienliche Hinweise erhofft, die ich auch
bekommen habe. Außerdem weiss ich jetzt auch, dass sich bis jetzt noch
keiner wirklich über das Design beschwert hat, oder Gründe vorgebracht hat,
warum es absolut untauglich ist.

Vielleicht kannst du ja auch noch etwas konstruktives beitragen.

Schönen Abend noch
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Oeffnungszeiten abbilden

Heiko Richler wrote:
>> +-----------+
>> | tblLaeden |
>> +-----------+
>> | LadenID |
| OeffnungszeitmodelID
>> | .. |
>> +-----------+
>
> +-------------------------+
> | tblOeffnungszeitenmodel |
> +-------------------------+
....
> +-------------------------+
>
>> +--------------------+
>> | tblOeffnungszeiten |
>> +--------------------+
....
>> +--------------------+

unter tblLaeden hatte ich einen Fremdschlüssel zu
tblOeffnungszeitenmodel nicht angegeben.

Heiko
--
http://portal.richler.de/ Namensportal zu Richler
http://www.richler.de/ Heiko Richler: Computer - Know How!
http://www.richler.info/ private Homepage