Moin!
Erik Tews wrote:
> Also, ich habe mir folgendes Überlegt, wenn ein Supporter ein
> Jobfragment immer ganz machen muss, dann brauchen wir die felder
> assignment.starttime und assignment.endtime eigentlich nicht mehr. Wir
> würden bei jeder Abfrage wo wir wissen wollen wann ein Supporter anfängt
> zu arbeiten einfach ein Join mit jobfragment machen, und uns von dort
> starttime und endtime holen. assignment.starttime und assignment.endtime
> müssen so ja immer identisch sein mit jobfragment.starttime und
> jobfragment.endtime. Eine Query die uns die Assignments ausgibt und
> jetzt so aussieht:
>
> select name, fragment, starttime, endtime from assignment;
>
> machen wir dann zu:
>
> select assignment.name, assignment.fragment, jobfragment.starttime,
> jobfragment.endtime from assignment, jobfragment where jobfragment.id =
> assignment.fragment;
Im Prinzip hast Du recht, ich wuerde so langsam allerdings ganz
gerne eine feste db-Struktur haben und sie nicht mehr dauernd
aendern.
Gegen das Loeschen spricht, dass es vielleicht wieder gestattet sein
soll, dass Jobs gesplittet werden (auch wenn es im Moment von der
Software nicht unterstuetzt wird), vielleicht wird dafuer noch ein
Flag im Fragment benoetigt, "splitting-permitted" o.ae. Die Datenstruktur
sollte flexibel genug sein, das aufzunehmen ohne dass wir muehsam
die neuen Felder einfuegen und mit Daten fuellen muessen.
Solange die Felder nicht stoeren, moechte ich sie in der
Tabelle bestehen lassen.
> Ich denke das würde z. B. das finden von fragmenten die noch
> unterbesetzt sind wesentlich vereinfachen.
Die Vereinfachung hast Du aber noch nicht beschrieben, das waere
der interessante Teil. :-)
Gruesse,
Joey
-- Experience is something you don't get until just after you need it.
This archive was generated by hypermail 2.1.3 : Mon May 20 2002 - 09:12:13 CEST