yo,
Ja, ist ein Überbleibsel aus alter Zeit. Es handelt sich um Personensätze, die jedoch auch eine Anschrift haben.
ok, ich würde der tabelle trotzdem einen personenbezogenen namen geben, aber das ist geschmackssache.
Nein, in den Mittagspausen und Abendstunden müssen die Personen nicht anwesend sein. Es macht Sinn, jede Anwesenheits-Stunde einzeln zu benennen, denn jede Stunde kann einzeln verplant werden.
ok...
mich wundert, dass es kein datum gibt.
Weil es sich um eine zweitägige Veranstaltung handelt. Die Zeiteinheiten 1-19 sind definitiv am 21.6., die 20-33 am 22.6. Dazu gibt es eine weitere Tabelle mit Datum und Uhrzeiten zwecks leserlichem Druck im Terminplan.
naja, selbst dann würde ich es in zeiträume zusammen fassen. es bildet die realität besser ab, kunde a hat ein treffen mit firma b von dann bis dann. meiner meinung nach würde das programm dann auch leichter feststellen können, ob sich zeiträume überlagern. mit zahlen von 1-33 wird es schwieriger.
Der Gesprächs- und Eventwunsch steht ZUNÄCHST ohne Zeitangabe im Raum. Es ist Aufgabe des Programms, zwischen Besuchern und Ausstellern eine gemeinsame freie Zeiteinheit zu finden, bei Events sind noch max. Teilnehmerzahlen zu berücksichtigen. Bei Treffern wird die gefundene Stunde in den Wunschsatz eingefügt.
selbst wenn es sich um wünsche handelt, dann sollte man die beziehungen nicht aus den augen verlieren. wenn ich das richtig verstanden habe, dann gibt es zu jedem treffen eines users genau einen gesprächspartner und ein wunsch. das würde ich versuchen, alles in eine tabelle unterzubringen. und zwar handelt es sich da um die beziehungstabelle von events und adressen (du siehst wie fürchterlich der name adressen hier wirkt).
also ein adresse (kunde) kann an mehreren events teilnehmen. und ein event kann von mehreren adressen ausgewählt werden. das ist eine klassische n:m beziehung und muss durch eine weitere beziehungstabelle dargestellt werden. und in dieser beziehungstabelle steht dann der gesprächspartner (wunschpartner) und sein eventwunsch. da du die stunden aufteilst (nicht von bis) musst du diese auslagern, ansonsten würde sie auch genau da mit rein gehören. aber was nörgeln wir immer über das db design herum. meistens läßt es sich ja sowieso nicht ändern.
Welche Beziehung fehlen (nach dieser Erklärung) noch?
das problem hat doch der join schon aufgezeigt. user 11 hat nach deinem beispiel 3 stundeneinheiten ausgewählt. aber welcher gesprächspartner gehört zu welcher stunde und welcher wunsch ?
zurück zu deiner abfrage. da du weder UNION noch unterabfragen seinsetzen kannst (armer Hund, wie Vinzenz schon sagte), sieht es düster aus. ich muss darüber noch mal in ruhe nachdenken. das geht aber im moment nur teilweise, weil nun das "perfekte dinner" im fernsehen anfängt und meine freundin das immer sieht und mich da immer mit fragen und aussagen einbezieht.....
Ilja