nicht angemeldet
Hi Ilja,
danke, dass du dich mit meinem Problem auseinandersetzt. Ich brauche wirklich das Gespräch mit Gleichgesinnten, bin schon voll betriebsblind in meinem LHO (Lonely Home Office).
Das System ist "im Rennen". Pferde (Konzepte) können jetzt nicht mehr ausgetauscht werden. Die Messe ist Mitte Juni, das System MUSS laufen. Trotzdem DANKE für konzeptionelle Anregungen, kann ich im nächsten Jahr gut gebrauchen.
ok, ich würde der tabelle trotzdem einen personenbezogenen namen geben, aber das ist geschmackssache.
Das habe ich auch, sprengt aber den Rahmen meiner Anfrage hier. Die alten Tabellennamen (aber identischer Aufbau) in mehreren Datenbanken unterscheiden sich und stehen in einem zweidimensionalen assoziativen PHP- Array:
$db = array (
array (
...
,'personen' => 'tm_adressen'
...
)
,
array (
...
,'personen' => 'bfp_adressen'
...
)
);
In PHP spreche ich die ORIGINAL-Personentabelle an mit
".$db[0]['personen']." AS per1
die KOPIE mit
".$db[1]['personen']." AS per1
aber das löst nicht mein Problem, sorry.
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.
Das Pogramm plant die Paarungen, es darf in keinem Fall zu Überlagerungen kommen. Ein Besucher kann niemals gleichzeitig im Workshop sitzen und zu Mittag essen.
ZUM VERSTÄNDNIS:
Besucher und Aussteller melden sich rechtzeitig an, bekommen in Schritt 2 Fragebögen und kreuzen ihre Wünsche an (Gesprächspartner und Events).
Jeder Wunsch erzeugt im System einen Datensatz und wird später auf Erfüllbarkeit überprüft.
Die kleinste Planungseinheit ist ein Slot (Zeiteinheit), vergleichbar mit dem Stundenplan in der Schule. Zwar ist z.B. ein Besucher IM STÜCK von Slot 2 bis Slot 19 (am ersten Tag) anwesend, kann aber in jedem Slot einen eigenständigen Gesprächstermin mit einem Aussteller (genau 1 Slot) haben ODER in einem Workshop (1 bis 2 Slots) sitzen ODER zu Mittag speisen (genau 2 Slots, auch als EVENT geführt).
Ja, auch das Mittagessen wird geplant, weil jedes der zwei Restaurants 350 Plätze bietet bei ca. 1200 Personen.
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.
Der Wunsch, dass Besucher B_01 den Aussteller A_55 sprechen möchte, ergibt einen Eintrag in der Tabelle "kontakte", zunächst mit dem Slot=0, also noch KEINE Buchung, sondern ein Wunsch.
Der Wunsch, dass Besucher B_01 die Teilnahme am Event E_12 (Erdgas - die Alternative für den Fuhrpark), E_15 (Innovationen im Automobilbau) und E_01 (Mittagessen) wünscht, gibt entsprechende Einträge in der Tabelle "eventbuchungen" mit Slot=0.
Der Besucher B_01 kann weitere Wünsche haben. Im Extremfall sogar mehr, als seine Anwesenheit in Slots zulässt. Das Programm kann nur freie Slots zu Terminen machen.
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).
Mmh, den Sinn kann ich nicht erkennen. Im Gegenteil: 2003 hatte ich noch Gesprächs- und Eventwünsche in einer Tabelle. Das war ein heilloses Durcheinander.
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.
GENAU. Das ist die Tabelle "eventbuchungen".
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.
NICHT VERSTANDEN, was du meinst.
Die Gespräche zwischen Besuchern und Ausstellern sind eine 1:1 Beziehung. Also ganz anders als die Events. Auch hier noch Sonderformen (mehrere Aussteller-Mitarbeiter können gleichzeitig getrennte Gespräche führen und mehrere Besucher, die als Gruppe ein gemeinsames Gespräch mit einem Aussteller führen. Okay, also 1:n).
Kalle