nicht angemeldet
DB-Design
Hallo Forum!
ich soll nach längerer Zeit wieder eine mySql-DB für Veranstaltungen (Ausstellungen,etc) erstellen.
Einige Felder der Einträge sollen auch nach zwei oder mehr Kriterien (mittels Auswahl- oder Dropdownliste) abrufbar sein,
am besten ohne das ich die Veranstaltung mehrfach anlegen muß.
zum Beispiel: der Veranstaltungszeitraum
(dessen Abruf um die Zeitabfrage zu vereinfachen nur nach Monaten möglich sein soll)
erstreckt sich bei einigen Austellungen über mehr als ein Monat. z. Bsp.:März, April..
oder eine Austellung kann auch 2 oder mehr Themen umfassen...
Jeder Datensatz abzurufen - wie erwähnt - nach jedem Kriterium, auch mit dem zweiten/dritten....
Wie kann eine solche DB gestalten ?
auch wenn ich z.bsp. die monate in eine eigene Tabelle auslagere muß ich in die Haupttabelle 2 oder mehr Fremdschlüssel einfügen(also unbrauchbar).
Oder kann man aus einem Textfeld (char, Varchar etc.) das z.Bsp. zwei Monate enthält, mit einer Auswahlliste
den Datensatz auch auslesen wenn man einen der beiden Begriffen einzeln auswählt?
Oder...?
Danke schon mal für eure Hilfe
Prampuri
-
Hallo
auch wenn ich z.bsp. die monate in eine eigene Tabelle auslagere muß ich in die Haupttabelle 2 oder mehr Fremdschlüssel einfügen(also unbrauchbar).
Oder kann man aus einem Textfeld (char, Varchar etc.) das z.Bsp. zwei Monate enthält, mit einer Auswahlliste
diese Idee ist genauso unbrauchbar.
Lege für diesen Fall eine Verknüpfungstabelle an mit
- Verweisen auf die Veranstaltungen
- Verweisen auf die Monate
Freundliche Grüße
Vinzenz
-
Hallo
Lege für diesen Fall eine Verknüpfungstabelle an mit
- Verweisen auf die Veranstaltungen
- Verweisen auf die Monate
danke für die schnelle Antwort.
meinst du eine m-n Beziehung ?
Gruß
Prampuri
-
Hallo,
meinst du eine m-n Beziehung ?
Du sagst es doch selber:
Eine Veranstaltung kann mehreren Monaten zugeordnet sein.
Einem Monat können mehrere Veranstaltungen zugeordnet sein.Freundliche Grüße
Vinzenz
-
Du sagst es doch selber:
Eine Veranstaltung kann mehreren Monaten zugeordnet sein.
Einem Monat können mehrere Veranstaltungen zugeordnet sein.es gibt glaub ich auch eine n-n Beziehung.
Es dauert einige Zeit bis ich das alles wieder in Erinnerung hab.
Bis alle Unsicherheiten ausgeräumt sind.Aber allerbesten Dank für deine Hilfe !
freundl. Grüße
Prampuri
-
Hi,
es gibt glaub ich auch eine n-n Beziehung.
hmh, wer kürzen kann ist klar im Vorteil:
Eine n:n-Beziehung bedeutet auf beiden Seiten gleiche Kardinalität. Das ist damit das Selbe wie eine 1:1-Beziehung. Sowas zu modellieren ist nur in Ausnahmefällen sinnvoll.MfG
Rouven--
-------------------
ie:| fl:| br:> va:| ls:& fo:) rl:( n4:{ ss:) de:] js:| ch:? mo:} zu:|
-
-
-
Moin!
zum Beispiel: der Veranstaltungszeitraum
(dessen Abruf um die Zeitabfrage zu vereinfachen nur nach Monaten möglich sein soll)
erstreckt sich bei einigen Austellungen über mehr als ein Monat. z. Bsp.:März, April..Eine Veranstaltung beginnt zu einem Zeitpunkt und endet zu einem späteren Zeitpunkt. Das sind exakt zwei Spalten "Start" und "Ende", welche mindestend vom Typ DATE, ggf. auch vom Typ DATETIME sein müssen. Mit passenden WHERE-Abfragen kann man dann jede beliebige Eingrenzung realisieren - auch die nach "Veranstaltungen im Zeitraum von Mai bis Juli".
Den Zeitraum der Veranstaltung durch eine n:m-Beziehung auf eine Monatsliste abzubilden ist keine gute Idee. Erstens ändert sich die Monatsliste nicht, ist also fix. Wäre deshalb stattdessen durch ein simples Feld vom Typ SET zu ersetzen (welches 12 Auswahlmöglichkeiten bietet für die 12 Monate). Und ist außerdem unnötige Redundanz, da man das exakte Datum der Veranstaltung sowieso speichern muß. Daraus läßt sich jederzeit auch der Monat bzw. die Monate generieren, in dem die Veranstaltung liegt.
oder eine Austellung kann auch 2 oder mehr Themen umfassen...
Das ist die klassische n:m-Beziehung, wie schon erwähnt wurde. Wobei "Thema" unpassend formuliert ist. Das Thema einer Veranstaltung ist hoffentlich einmalig bzw. eindeutig, und steht direkt im Datensatz der Veranstaltung. Was vermutlich gemeint ist, ist "Themengebiet" bzw. "Themenkategorie", von denen es mehrere vordefinierte (und ggf. zu erweiternde) Möglichkeiten gibt.
- Sven Rautenberg
--
My sssignature, my preciousssss!-
yo,
Eine Veranstaltung beginnt zu einem Zeitpunkt und endet zu einem späteren Zeitpunkt. Das sind exakt zwei Spalten "Start" und "Ende"
als ergänzung vielleicht noch, dass man nicht unbedinkt einen endpunkt braucht, sondern es auch über eine startwert und eine länge realisieren kann. beides sind gehbare möglichkeiten.
Den Zeitraum der Veranstaltung durch eine n:m-Beziehung auf eine Monatsliste abzubilden ist keine gute Idee. Erstens ändert sich die Monatsliste nicht, ist also fix.
ob eine entität feste werte hat oder nicht, ist kein grund sie nicht trotzdem aufzunehmen, solange sie bestandteil des abzubildenen modells ist.
Und ist außerdem unnötige Redundanz, da man das exakte Datum der Veranstaltung sowieso speichern muß. Daraus läßt sich jederzeit auch der Monat bzw. die Monate generieren, in dem die Veranstaltung liegt.
zum einen ensteht dadurch keine redundanz, wenn man die monate in einer extra tabelle aufnimmt. alles andere wären fremdschlüssel und diese stellen keine redundanz da. und wenn ich die entitäts-tabelle ganz weglasse und die monate durch die beziehungs-tabelle herleite, dann kann es zu schwierigkeiten führen, da man nicht automatisch davon ausgehen kann, dass immer alle monate dort aufgeführt werden. so muss ich bestimmte abfragen in deinem falle in eine programmlogik auslagern, die zudem alle monate kennen muss, wenn ich zum beispiel wissen will, in welchen monaten gibt es keine veranstaltungen. dann kann ich das nicht mehr mit SQL abfragen, da die datenbank keine monate kennt, die nicht auch dort aufgeführt werden.
Ilja
-