"We are back" « oc.at

Kalender coden...

DJ_Cyberdance 30.05.2005 - 12:44 806 7
Posts

DJ_Cyberdance

Here to stay
Avatar
Registered: Jun 2002
Location: Vesterålen
Posts: 1838
Hallo!
Ich hab da Software zum Verwalten von diversen Kursen. Die haben einen Starttermin und einen Endtermin sowie entsprechende Uhrzeiten. Ein Administrator kann diese Kurse erstellen und die Benutzer oder Kunden sollen nun eine Art Stundenplan sehen können wann was stattfindet. Das ganze soll natürlich dynamisch sein.

Wie mach ich das nun am klügsten? Die ganzen Kursdaten sind in einer MySQL-Datenbank abgelegt. Ich hätt folgende Idee, aber vielleicht weiß ja jemand einen professionelleren Ansatz:

Admin kann einen Kurs anlegen. Software rechnet die Termine aus, Admin kann sie dann bearbeiten (zB wenn Kurs in einer Woche ausfällt oder Feiertag is oder wwi).

Dann hab ich in dieser Datenbank eine eigene Tabelle mit den Feldern:
Kurs_ID, Datum, Uhrzeitvon, Uhrzeitbis

In dieser Tabelle sind für einen Kurs mit 8 Einheiten also auch 8 Einträge drin, aus denen ich dann einen Stundenplan basteln kann.

Gibts für sowas prinzipiell andere Ansätze? Sind besser geeignet? Warum?

Ach ja, ich verwende PHP für diese Sache, aber das spielt im Grunde keine Rolle, es geht nur ums Prinzip.

watchout

Legend
undead
Avatar
Registered: Nov 2000
Location: Off the grid.
Posts: 6845
das kommt immer drauf an. Prinzipiell ist dein Ansatz gut wenn du eine Dokumentation im nachhinein brauchst. (Könnte man aber auch durch ein Log realisieren) Schlecht is es in der Hinsicht dass du relativ bald relativ viele Datensätze hast, aber eigentlich eh immer nur am gleichen Tag zur gleichen Zeit jede Woche, und sich das eigentlich auch durch genau einen Datensatz auch lösen lassen würde, sowie etwaigen aufhebenden (entfällt), die aber aufgrund ihrer geringen Datenmenge eher uninteressant sein würden.

Um einen Termin auch oder gerade nicht an Feiertagen zu setzen reicht ein Boolean-Wert und eine mehr oder weniger aufwändige Berechnung in PHP (normal kann man sagen ein Termin findet an feiertagen statt - oder eben nicht).

Somit ist die Sache auch eine Frage wo du mehr Leistung zur Verfügung hast - nämlich bei deiner Datenbank oder bei PHP (Du hast nicht geschrieben in welchem Umfang das ganze geschieht, also nehme ich einen grossen an da du dir so viele Gedanken machst)

hth

pong

Addicted
Avatar
Registered: Oct 2001
Location: Wien (ned im Kra..
Posts: 414
Uiui, deine Datenbank solltest dir mal ordentlich überlegen, denn mit einer Tabelle fangst nicht viel an. Ich persönlich würde so etwa anfangen

kunde (uid, name... <sonstige Daten>;)
Trainer (tid, name, <sonstiges>;)
Kurs (kid, einheiten, Bezeichung, Preis)
kurs_plan (kpid, tid, kid, einheit, von(ts), bis(ts), status(ok/verschoben -> kpid der neuen Einheit))
kurs_plan_kunde (uid, kpid, status (verschoben, abgesagt, besucht...))

Ist sicher nicht ideal aber sicher ein Richtungsweisender Beginn

Auf welcher Plattform/Umgebung hast du denn vor, dies zu realisieren?

pong

Longbow

Here to stay
Avatar
Registered: Feb 2003
Location: Homeoffice
Posts: 5418
wir haben mal in der schule genau so ein beispiel mit kursen und so in excel gemacht, mal gucken

DJ_Cyberdance

Here to stay
Avatar
Registered: Jun 2002
Location: Vesterålen
Posts: 1838
@pong: Danke, aber Datenbank gibts bereits in ähnlicher Form. Soll nur um diese Kalenderfunktion erweitert werden.

@watchout: Thx, auch ein guter Ansatz... Aber das ganze sollt sehr flexibel sein, manche Kurse sind nur übers Wochenende, andere wöchentlich und können auch an Nicht-Feiertagen ausfallen (Trainer nicht anwesend). Als groß würd ich den Umfang nicht bezeichnen, sagen wir eher unterdurchschnittlich... daweil jedenfalls.

Umgebung:
P4, 2.4GHz, 1GB RAM, Linux, PHP 4.3.10, 100mbit

thx 4 help!

watchout

Legend
undead
Avatar
Registered: Nov 2000
Location: Off the grid.
Posts: 6845
Zitat von DJ_Cyberdance
@pong: Danke, aber Datenbank gibts bereits in ähnlicher Form. Soll nur um diese Kalenderfunktion erweitert werden.

@watchout: Thx, auch ein guter Ansatz... Aber das ganze sollt sehr flexibel sein, manche Kurse sind nur übers Wochenende, andere wöchentlich und können auch an Nicht-Feiertagen ausfallen (Trainer nicht anwesend). Als groß würd ich den Umfang nicht bezeichnen, sagen wir eher unterdurchschnittlich... daweil jedenfalls.

Umgebung:
P4, 2.4GHz, 1GB RAM, Linux, PHP 4.3.10, 100mbit

thx 4 help!
also, bei unterdurchschnittlicher auslastung solltest du dir um performance keine Gedanken machen müssen, schätze ich... Da wirst du wohl mit einem "sauberen" Datenbankdesign weiter kommen

Wenn du sagst die Datenbank existiert schon, worin besteht jetzt deine Frage? :confused:

Ein Admin-User System ist klassisch für so eine Anwendung und nach zB. dem Wiki-System fällt mir keine brauchbare Lösungsvariante ein...

DJ_Cyberdance

Here to stay
Avatar
Registered: Jun 2002
Location: Vesterålen
Posts: 1838
Zitat von watchout
Wenn du sagst die Datenbank existiert schon, worin besteht jetzt deine Frage? :confused:

Die Datenbank besteht ohne Kalender... und ich hab noch nie so einen Kalender gemacht und wollt einfach andere Lösungsansätze hören. Was meinst Du mit "sauberem Datenbankdesign", schließt das meinen Vorschlag ein oder aus Deiner Meinung nach?

watchout

Legend
undead
Avatar
Registered: Nov 2000
Location: Off the grid.
Posts: 6845
Zitat von DJ_Cyberdance
Die Datenbank besteht ohne Kalender... und ich hab noch nie so einen Kalender gemacht und wollt einfach andere Lösungsansätze hören. Was meinst Du mit "sauberem Datenbankdesign", schließt das meinen Vorschlag ein oder aus Deiner Meinung nach?
Trotzdem weiss ich noch immer nicht worin deine Frage jetzt besteht...

Als sauberes design sehe ichs wenn die DB die Daten in Reinform und keine doppelten Keys, Daten hast. zb. den Kursleiter zusätzlich als String direkt in die einzelnen Kurseinträge einzutragen könnte die Performance deines Scripts erhöhen weil du dir einen join sparst - aber sauber is das nicht mehr.
Ein sauberes Design macht sich in der Zukunft bezahlt, wenn du Erweiterungen vornehmen willst.

Aber ich schätze das war dir eh klar...
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz