Moin!
Erik Tews wrote:
> Also, vom Prinzip her stelle ich mir folgendes Datenbankformat vor
>
> Wir haben 3 Tabellen, einmal Helfer-Zeit, Aufgaben und Zuweisung
Siehe unten, ich denke, das ist zu wenig.
> Die Helfer-Zeit Tabelle kennt folgende Felder
>
> Name (text): Name des Helfers der in personen eingetragen ist
>
> Start (timestamp): Zeitpunkt ab wann der Helfer Zeit hat
>
> Ende (timestamp): Zeitpunkt bis wann der Helfer Zeit hat
>
> Commt (text): Möglichkeit ein Kommentar zu äusern, also z. B. so etwas
> wie "Ist noch nicht sicher ob ich heute schon ankomme oder
> morgen, deswegen bitte nur mit wem zusammen einteilen, der
> die Arbeit zur Not falls was dazwischenkommt auch alleine
> machen kann"
1:n oder 1:1 Beziehung mit der Personentabelle? Falls 1:1: Wie
modellieren wir den folgenden Fall:
Joey: Do: 10-14 ok, 16-20 auch ok, zwischendurch nicht da.
> Die Aufgaben-Tabelle sieht vom Prinzip genauso aus
>
> Id (serial): Eine ID, die diese Aufgabe beschreibt
Automatisch zu vergeben vom LTP, nicht von PostgreSQL.
> Aufgabe (text): Text der die Aufgabe vom Prinzip her beschreibt
>
> Anzahlmin (int4):
> Anzahlmax (int4): Anzahl der Personen die für die Aufgabe gebraucht
> werden (Minimum und Maximum)
Btw. wieso INT4 und nicht INT2? Meinst Du, daß wir mit -32768 to
+32767 nicht auskommen?
> Ort (text): Wo die Aufgabe stattfindet
>
> Start (timestamp): Zeitpunkt ab wann es losgeht
>
> Ende (timestamp): Zeitpunkt bis wann es dauert
>
> Bemerkung (text): Zusatzinformationen, also z. B. wie "Mindestens eine
> Person sollte mit Videokamera umgehen können"
>
> Priorität (int4): Priorität der Aufgabe (Optional)
>
> Beim CCC wurde es z. B. immer so gehandhabt, dass erst die Leute für
> Sicherheitsengel eingeteilt wurden. Erst wenn da alle Posten besetzt
> waren, die man brauchte wurden die anderen Schichten eingeteilt.
Doch, wir haben auch hier Prioritäten. Das habe ich bisher noch nicht
so betrachtet, aber immer so gehandhabt Vortragshelfer >> Fahrdienst,
Vortragshelfer >> Workshophelfer, Workshophelfer >> Postdienst etc.
Oh ha... das wird interessant, wenn wir die vergeben...
Btw. wieso INT4 und nicht INT2? Meinst Du, daß wir mit -32768 to
+32767 nicht auskommen?
Wie modellierst Du mit obiger Darstellung folgende Situationen:
1. Eingangskontrolle Social Event: 18:00 - 22:00 in Stundenschichten
á 2 Personen
2. Jeden Abend um 19 Uhr Müll einsammeln. Dauer 1/2 Stunde.
> Die Zuweisungtabelle sieht wie folgt aus:
>
> Id (int4): Referenz auf die Aufgabentabelle
>
> Helfer (text): Name des Helfers der eingeteilt wurde
>
> Start (timestamp): Zeitpunkt ab wann der Helfer die Aufgabe übernimmt
>
> Ende (timestamp): Zeitpunkt bis wann der Helfer die Aufgabe übernimmt
> Beispiel:
>
> Es geht darum, dass eine Kasse besetzt werden soll. Es werden mindestens
> immer 2 Leute gebraucht, da die Kasse immer besetzt sein soll, und einer
> mal kurzeitig aufs Klo gehen können muss. Ab 12:00 Uhr Mittags bis 15:00
> ist immer stärkerer Andrang, also braucht man da 3 Leute an der Kasse.
>
> Dann könnte man die Aufgabentabelle wie folgt füllen:
>
> Id: 1
> Aufgabe: Kassendienst Frühschicht
> Anzahlmin: 2
> Anzahlmax: 3
> Ort: Kasse
> Start: 6.5.2002 8:00 Uhr
> Ende: 6.5.2002 12:00 Uhr
> Bemerkung:
> Priorität: 1 (1 bedeutet hoch)
>
> Id: 2
> Aufgabe: Kassendienst Mittag
> Anzahlmin: 3
> Anzahlmax: 5
> Ort: Kasse
> Start: 6.5.2002 12:00 Uhr
> Ende: 6.5.2002 15:00 Uhr
> Bemerkung:
> Priorität: 1
>
> Id: 3
> Aufgabe: Kassendienst Spätschicht
> Anzahlmin: 2
> Anzahlmax: 3
> Ort: Kasse
> Start: 6.5.2002 15:00 Uhr
> Ende: 6.5.2002 20:00 Uhr
> Bemerkung: Ende kann sich je nach Situation noch etwas herauszögern
> Priorität: 1
Mir gefällt daran nicht, daß ich für die gleiche Aufgabe drei
Datensätze und drei Jobs habe.
Dann laß uns lieber etwas in diese Art machen:
[Tabelle: Aufgabenbeschreibung] 1:n [Tabelle: Aufgabe]
z.B. hier Kassendienst da: 8-12, 12-15 und 15-20
hier Mülleinsammeln Do: 19h, Fr: 19h, Sa: 19h, So: 18h
Ich spinne das mal wie folgt weiter. In Ermangelung eines Scanners
nur eine sehr einfache Grafik
Table Availability
Person
| n
| (fk: person.name = availability.person)
| 1
Table Person
Name
| 1
| (fk: person.name = job_assoc.person)
| n
Job-Association
Person
Fragment
| 1
| (fk: job_assoc.fragment = fragment.id)
| (und: [job_assoc.start,job_assoc.end] in [fragment.start,fragment.end])
| 1
Job-Fragment
Id
JobID
| n
| (fk: job.id = fragment.jobid)
| 1
Job
Id
Ok, erscheint mir möglich, allerdings bereitet mir die Aufteilung von
Job-Fragmenten auf verschiedene Helfer Kopfzerbrechen.
> Nun gehen wir von folgendem Szenario aus:
>
> Helfer Erik ist den ganzen Tag lang an der Kasse
> Helfer Joey kann ab 9:00 Uhr bis 14:00 Uhr
> Helfer Peter kann den ganzen Tag, möchte aber wenn es geht viel
> Freitzeit haben.
> Helfer Klaus ist ab 12:00 Uhr da, und hat bis Abends Zeit
>
> Man würde also die Zuweisungstabelle so ausfüllen:
>
> Id: 1
> Helfer: Erik
> Start: 8:00 Uhr
> Ende: 12:00 Uhr
>
> Id: 2
> Helfer: Erik
> Start: 12:00 Uhr
> Ende: 15:00 Uhr
>
> Id: 3
> Helfer: Erik
> Start: 15:00 Uhr
> Ende: 20:00 Uhr
>
> Id: 1
> Helfer: Joey
> Start: 9:00 Uhr
> Ende: 12:00 Uhr
>
> Id: 2
> Helfer: Joey
> Start: 12:00 Uhr
> Ende: 14:00 Uhr
>
> Id: 2
> Helfer: Klaus
> Start: 14:00 Uhr
> Ende: 15:00 Uhr
>
> Id: 3
> Helfer: Klaus
> Start: 15:00 Uhr
> Ende: 20:00 Uhr
>
> Id: 1
> Helfer: Peter
> Start: 8:00 Uhr
> Ende: 9:00 Uhr
>
> So in etwa könnte dann die Zuweisung aussehen. Ich denke damit sollte
> man in der Lage sein, alle Möglichen konstellationen zu berücksichtigen.
Laßt sich das halbwegs sinnvoll auf SQL-Queries abbilden oder müssen
wir eine komplexe Logik in die PHP-Seiten und das Perl-Programm legen?
Insesondere die etwas komplizierteren Zusammenhänge wie Aufteilung von
mehrstündigen Jobs auf mehrere Personen (Splitting).
Ich zitiere mal aus .../todo und kommentiere:
> . Collect names, (mail) addresses and phone numbers
Trivial.
> . Collect information about when somebody is available for help and
> when not. Those people would often like to listen to one talk or
> another, when it's interesting, so we should take allow off-duty
> time.
Weniger trivial... Aufbereitung muß in die Applikation verlagert
werden, aber möglich.
> . Collect a list of tasks that need to be fulfilled by supporters
> during the show. Also collect the day and time when it needs to be
Trivial. Zusammen mit Zeiten komplizierter. Aufbereitung muß in die
Applikation verlagert werden, aber möglich.
> done. Like supporting a talk is a regular task, but fetching
> somebody from the airport or train station only needs to be done
> once.
Erscheint möglich.
> . Create a list of people who are available for support but are
> actually not bound to a particuliar task. This is very important
> since, all the time, there is a suddon need for help and we *have
> to know* who is available in such a case.
Kann nicht mit dem Datenmodell, sondern nur aufwendig in der
Applikation geschehen, oder sehe ich das falsch?
> . Create a list of all tasks that have to be done, and connect names
> of supporters to them, together with the time, visualizing who is
> supporting which at what time. This will actually help us knowing
> who is doing what at the moment.
Nicht trivial, aber mit aufwendiger Applikation möglich. Oh weia, da
kommt noch einiges auf uns zu...
> . Split this list up by groups, i.e. talk jobs/supporters, workshop
> jobs/supporters, general jobs/supporters etc.
Einführen von job.group TEXT und wir können nach Belieben gruppieren.
> . Create a (large, sorry) list of supporters and which tasks they are
> supporting at what time, when they don't have a duty yet and when
> they are off duty. This information will be kept up-to-date
> offline by placing it at a wall and letting people write into it.
> This, however, is one of the most important thing, since it gives
> us an overview of who is around, who should be around etc.
Mit dem obigen und Aufwand machbar. Wei oh wei...
> Alternativ könnte ich das noch so ausweiten, dass man Zweitbesetzungen
> einteilen kann, wenn die Erstbesetzung ausfällt. Sag mir mal deine
> Meinung dazu.
Ich denke nicht, daß die Zweitbesetzung nötig ist.
Bekommen wir das obige denn zusammen zeitnah implementiert?
Gruesse,
Joey
-- Those who don't understand Unix are condemned to reinvent it, poorly.
This archive was generated by hypermail 2.1.3 : Sun May 05 2002 - 16:27:13 CEST