Kalle_: Datenbank-Design

Beitrag lesen

Hello,

Ich fasse nochmal zusammen:

Es gibt Besucher   (B)
Es gibt Aussteller (A)
und es gibt Zeit   (Z)

Ja, und noch Prioritäten, denn nicht alle 6.000 Gesprächswünsche können erfüllt werden. Also werden zunächst die mit Priorität 1 ... und so weiter.

Die Gruppierung heißt also:  B spricht A um Z

Ja, genau.

Du benötigst also drei Indexe:

B - A           Ein Gespräch zwischen Aussteller und Besucher reicht

A - Z           Wenn A um Z schon belegt ist, kann er
                  gleichzeitig keinen zweiten Termin wahrnehmen

B - Z           Wenn B um Z schon belegt ist, kann er
                  gleichzeitig keinen zweiten Termin wahrnehmen

Durch Terminwunsch und Ausweichterminwunsch kannst Du ggf. die Sache entkrampfen.
Denn es gelten die rahmenbedingungen: nicht jeder kann zu jeder Zeit.

Du müsstest also ein Raster im Maß der Gesprächsterminlänge bilden.

Ja, das wird Slot genannt. Jeder Slot hat eine Nummer und eine zeit_von, zeit_bis.

Es wäre auch möglich, einem Pärchen mehrere zusammenhängende Einheiten zu geben. usw.

Ja, gibt es sogar, Workshops mit mehreren Teilnehmern. Aber das ist eine andere Baustelle, beeinflusst jedoch die Restzeit der Besucher.

Aber ich denke, die Vorgehensweise sollte Dir nun klar sein.

Lass mich drüber nachdenken, ob die Datenpflege einfacher wird. Das war ja das Hauptproblem.

Zur Berechnung von 6000 Paarungen (oder Tripelungen) benötigt man keine Datenbank, sondern einen Arbeisspeicher mit z.B.

(6000 * 2 * 3 Byte) + (6000 * 32 Byte) pro Arrayelement

=> ca. 196kByte

Das sollte PHP locker zur Verfügung haben.

Ja, gute Idee, geht sicher schneller, muss dann aber in der DB gespeichert werden, damit der "Stundenplan" zu beliebiger Zeit abrufbar und druckbar ist.

Danke dir.

LG Kalle