On Sun, May 05, 2002 at 04:24:26PM +0200, Martin Schulze wrote:
> 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:
Ist 1:n, kein Problem damit.
> > Die Aufgaben-Tabelle sieht vom Prinzip genauso aus
> >
> > Id (serial): Eine ID, die diese Aufgabe beschreibt
>
> Automatisch zu vergeben vom LTP, nicht von PostgreSQL.
Jaja, schon klar, deswegen ja serial.
> > 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?
OK, wird auf INT2 geändert.
> > 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...
OK, machen wir so. Wer welche Zahl bekommt musst du dir überlegen.
> Wie modellierst Du mit obiger Darstellung folgende Situationen:
>
> 1. Eingangskontrolle Social Event: 18:00 - 22:00 in Stundenschichten
> á 2 Personen
Also, ich würde dann einen Eintrag machen, von 18:00 bis 22:00 Uhr, und
noch dazuschreiben "Bitte nur Stundenweise eintragen". Alternativ könnte
man 4 Einträge machen mit Eingangskontrolle Schicht 1, Eingagskontrolle
Schicht 2.... wie man will.
> 2. Jeden Abend um 19 Uhr Müll einsammeln. Dauer 1/2 Stunde.
Für jeden Tag einen Eintrag.
> > 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
OK, angenommen, so machen wir es.
> 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, angenommen, ich setz das mal in SQL um.
> 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).
Also, für die Darstellung wann wer frei hat und wann wer was zu tun hat,
müssen wir wohl die Logik in PHP machen, das wird aber nicht schwierig,
da hab ich mir schon nen halbwegs gescheiten Algo ausgedacht.
> Ich zitiere mal aus .../todo und kommentiere:
>
> > . Collect names, (mail) addresses and phone numbers
>
> Trivial.
Jup
> > . 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.
Ja, das wird man schon hinbekommen.
> > . 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.
Geht schon.
> > 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.
Geht.
> > . 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?
Naja, aufwendig würde ich nicht sagen, wir schauen wieviel Uhr es ist,
ob der jenige jetzt gerade sich als Verfügbar eingetragen hat, und gehen
dann alle seine Tasks ab, und schauen, ob einer jetzt stattfindet.
> > . 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...
Och, das sehe ich als Einfach an.
> > . 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.
Jo
> > . 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...
Wenn da wer reinschreibt muss das aber dann auch in die DB.
> > 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?
Also, ich sag mal, das geht.
This archive was generated by hypermail 2.1.3 : Sun May 05 2002 - 16:52:47 CEST