DB-Layout. Achtung, lang

[Kalle_B]

Hallöle,

da mir der Kopf raucht und kein fachkundiger Gesprächspartner zur Verfügung steht, möchte ich ein Problem vortragen. Viellicht hilft mir ja schon das Formulieren, um etwas mehr Klarheit zu schaffen. Oder ein kleiner Tipp von euch, um eine Lücke im Konzept zu erkennen.

Im vierten Jahr programmiere ich das Terminmanagement für eine jähllich wiederkehrende Messeveranstaltung. Es geht darum, jedem Aussteller und jedem Besucher einen "Stundenplan" zu erstellen.

Die Tabellen sind im Wesentlichen noch so wie vor vier Jahren (auch mein Kenntnisstand von 2003), aber es sind Aufgaben dazugekommen, insbesondere Selektionen (Filterfunktionen) zur Feinabstimmung bei den Buchungen.

Eine Neuorganisation der DB ist nahezu ausgeschlossen, 40 Programme müssten geändert und getestet werden.

Die DB hat (nur) 8 Tabellen:

• Adressen (Aussteller und Besucher)
• Anwesenheit
• Eventbuchungen (Besucherwünsche und Termine zu Events)
• Events
• Gruppen
• Besucher_zu_Gruppen
• Kontakte (Besucher- und Ausstellerwünsche und Termine zu Gesprächen)
• Slots

G-R-U-N-D-D-A-T-E-N
(in Klammern: ungefähre Anzahl der Datensätze)

ADRESSEN, bestehend aus

AUSSTELLERFIRMEN (60)
AUSSTELLERMITARBEITER (250)
Eine Ausstellerfirma hat bis zu 6 Mitarbeiter vor Ort, kann also max. 6 Besuchergruppen pro Zeiteinheit empfangen.

• kreuzen an, mit welcher Besucherfirma sie Kontakt wünschen.

BESUCHERFIRMEN (450)
BESUCHERMITARBEITER (600)

• kreuzen an, mit welchem Aussteller sie ein Gespräch wünschen.
• kreuzen sie an, an welchem Event sie teilnehmen möchten.
• geben ggf. andere Einzelbesucher an, mit denen sie eine Gruppe bilden wollen, auch aus anderen Firmen. Gruppe heißt: Gemeinsame Interessen (Events und Aussteller) gemeinsam wahrnehmen, unterschiedliche Interessen einzeln wahrnehmen.

ANWESENHEIT (18000,  max. 35 * (250 + 600))
Für jede Einzelperson und jeden Anwesenheitsslot ein Datensatz.

EVENTBUCHUNGEN
Besucheranmeldungen zu Events. Im Buchungsfall ergänzt durch die gefundene Folge event_id und von_slot_nr, bis_slot_nr

EVENTS
Workshops, Arbeitsgruppen, Vorträge, Mittagessen mit festen Terminen und max. Teilnehmerzahl über einen oder zwei aufeinanderfolgende Slots.
Jedes Event kann Folge- Events haben, also gleichwertige Veranstaltungen zu einem anderen Zeitraum. Der Besucherwunsch bezieht sich aufs Hauptevent.

GRUPPEN (100)
nur eine Zählnummer ohne weiteren Inhalt

BESUCHER-ZU-GRUPPEN (200)
Jeder Besucher kann keiner oder einer Gruppe angehören, nicht mehreren Gruppen. Eine Gruppe besteht überwiegend aus zwei Personen, manchmal drei.

KONTAKTE (9000)

• für jeden Besucherwunsch BESUCHERMITARBEITER - AUSSTELLERFIRMA ein Datensatz.
• für jeden Ausstellerwunsch BESUCHERFIRMA - AUSSTELLERFIRMA ein Datensatz.
  Übereinstimmungen werden schon bei der Eingabe zu einem Datensatz zusammengelegt mit höherer Priorität.

SLOTS (35)

• Zeiteinheiten, in denen Events und Kontakte stattfinden.

B-U-C-H-U-N-G-E-N

EVENTBUCHUNGEN
Zuerst werden die Eventwünsche der Besucher zu Terminen. Das läuft problemlos. Damit sind bei den Besuchern also Slots belegt, manchmal die gesamte Anwesenheitszeit.

KONTAKTBUCHUNGEN
Hiermit habe ich Riesenschwierigkeiten.

Zuerst der Standard (keine Filter aktiv):
Die zu buchenden Slots werden durchlaufen (Checkbox).

Pro Slot werden die anwesenden und freien Aussteller- Mitarbeiter geholt und deren Firma ermittelt. Das erfolgt einaml zu Beginn des  Buchungslaufs.

Pro Ausstellungsfirma die anwesenden und freien Besucher, die diese Firma wollen, aber noch nicht haben.

Zu den Besuchern eventuelle Gruppenmitglieder, die auch diesen Aussteller wollen, nicht haben und zur gleichen Zeit anwesend und frei sind.

Gruppenmitglieder, die nicht anwesend oder nicht frei sind, verwerfen die ganze Gruppe. Prinzip: Alle oder keiner. Genaugenommen handelt es sich hier um Untergruppen, also die Mitglieder, die denselben Aussteller wollen. Die Gruppe kann weitere Mitglieder haben.

Sortierung: Zuerst die Gruppen mit den meisten Mitgliedern, also 3, dann 2, dann 1 (nur 1 Gruppenmitglied möchte mit diesem Aussteller sprechen).

Bei Wechsel der Aussteller- Firma müssen die Besucher für diese Firma neu gelesen werden. Es könnten dieselben Besucher sein, die soeben gebucht wurden und jetzt nicht mehr frei sind.

P-R-O-B-L-E-M

Besucher zu den Ausstellern finden.

Die Kombinationen sind dermassen vielfältig, dass mir das richtige Lösungskonzept fehlt. Habe mehrere Ansätz ausprobiert.

Entweder ich lese und schreibe kleine Mengen dauernd auf der Datenbank, was die Laufzeit aufbläht und sehr viel Programmlogik erfordert. Da schlägt schon mal der Timeout von PHP zu und ich habe eine undefinierte Datenbank.

Oder ich tüftle wenige SQL- Kommandos mit großen Treffermengen aus, die ich zwar auf die ersten 6 (bei 6 Aussteller- Mitarbeitern) begrenzen kann, aber der Kombination aus JOINS sowie AND- und OR- Verknüpfungen nicht Herr werde.

Irgendwie fehlt der dritte Lösungsweg.

Danke an alle, die bis hierher durchgelesen haben.

Lieben Gruß, Kalle

[Tom]

Hello Kalle,

du solltest zu dieer Frage eine Webpage öffnen, wo Du auch grafische Darstellungen der üblichen Art abbilden kannst. Die sollte dann immer fortgeschrieben werden, also es auch möglich machen, den Stand der Dinge über mehrere Stufen nachvollziehen zu können.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[King^Lully]

Die Tabellen sind im Wesentlichen noch so wie vor vier Jahren (auch mein Kenntnisstand von 2003), aber es sind Aufgaben dazugekommen, insbesondere Selektionen (Filterfunktionen) zur Feinabstimmung bei den Buchungen.

Eventuell macht es Sinn einfach mal zu schildern welche neuen Funktionalitäten hinzuzubauen sind und woran das zu scheitern droht.
Schildere in diesem Zusammenhang auch das Datendesign.
Schreib noch mal, obs MySQL ist (habs zumindest nicht gelesen) und wie der Datenzugriff implementiert ist, also warum Änderungen am Design unmöglich erscheinen.

[King^Lully]

Kommt da noch was oder wars das schon?