verschachtelte query für Cronjob

tinchen · 04.08.2006, 21:52

Nabend zusammen,

ich habe wieder mal eine Vielzahl von Möglichkeiten durchprobiert (Joins, mehrere foreach Geschichten, ...) aber nichts von dem erfüllt das, was ich möchte.

Ich möchte einen Cronjob zu einer bestimmten Zeit, als auch bei einer bestimmten Aktion ausführen.

In einer Datenbanktalle werden User mit einer bestimmten Eigenschaft (status) zu einem event zugeordnet.
Um ein Beispiel zu nennen:
user_id | event_id | status | zeitstempel
1 | 23 | 1 | 2006-08-04 19:37:02
2 | 23 | 1 | 2006-08-04 19:37:22
3 | 23 | 2 | 2006-08-04 19:37:32

Der Status 1 bedeutet letztendlich das die Person diesen Event fest gebucht hat, bei Status 2 befindet er sich auf der Nachrückerliste, weil die Veranstaltung z.B. nur für 2 Personen ausgelegt ist. Die Daten werden bereits geschrieben, lassen sich verwalten und löschen.

Löscht der User 2 seine Belegung soll User 3 automatisch nachrücken.
Dieses soll bei der Aktion des Löschens und zur Sicherheit noch einmal per Cronjob ausgeführt werden.

Die Anzahl der Plätze findet sich in einer anderen Tabelle.
event_id | free_places | ....
23 | 2 | ...

Wie mache ich das am besten von der Idee her?

Gruß
Tine

xabbuh · 04.08.2006, 22:35

Mal eine allgemeine Frage: Warum vergibst du überhaupt Flags, um einen Benutzer als "fest gebucht", "Nachrücker" etc. zu kennzeichnen? Wäre es für dein Script nicht möglicherweise ausreichend, anhand der Reihenfolge der Eintragszeit zu ermitteln, ob ein Benutzer noch innerhalb des zur Verfügung stehenden Kontingent liegt oder nicht?

Wenn du nun trotzdem bei deinem Weg bleiben möchtest, solltest du dir - MySQL 5.0 oder höher vorrausgesetzt - in der MySQL-Dokumentation das Kapitel über Trigger ansehen: http://dev.mysql.com/doc/refman/5.0/en/triggers.html

tinchen · 04.08.2006, 23:31

Leider geht das nicht, da es in Wirklichkeit noch sehr viel komplexer ist. Es gibt
Bestätigungen, Zurückmeldungen in bestimmten Zeiträumen etc. Es gibt derzeit 5
verschiede Möglichkeiten den Status zu beschreiben.

MySQL bewegt es sich derzeit in 4.1.12.

Meine ersten Ideen sehen so oder so ähnlich aus, allerdings nicht wirklich zu
gebrauchen.

PHP-Code:

  $query = "SELECT distinct(a.event_id), a.v_free FROM jos_skiba_veranstaltungen AS a

             INNER JOIN jos_skiba_buchung AS b ON b.event_id=b.event_id

             ORDER BY b.zeitstempel ASC"    

            ;

        $database->setQuery( $query );

        $rows = $database->loadObjectList();

 
            foreach ( $rows as $row ) {

                

                $query = "SELECT count(status) FROM jos_skiba_buchung

                    WHERE event_id=$row->event_id

                    AND (status=1 OR status=5)"

                    ;

                $database->setQuery( $query );

                $total_bookings = $database->loadResult();

 
                $query = "SELECT count(status) FROM jos_skiba_buchung

                    WHERE event_id=$row->event_id

                    AND (status=3)"

                    ;

                $database->setQuery( $query );

                $statuscheck = $database->loadResult();

 
                    if($total_bookings<$row->v_free && $statuscheck) {

 
                        $query = "UPDATE jos_skiba_buchung SET status=1 WHERE status=3 AND event_id=$row->event_id";

                        $database->setQuery($query);

                        $database->query();

 
                    }

                }

Geht nur teilweise, wenn die Bedingung erfüllt ist, bekommen alle User den Status 1
zugewiesen. Also so geht es nicht wirklich.

Gruß
Tine

pepe24 · 05.08.2006, 16:42

Leider ist es schwer, nachzuvollziehen, was Du da genau tust. Kommentare sind dazu einfach unumgänglich!

Kannst Du das <select> statement in der foreach schleife nicht umgehen?
Außerdem ist da ein semantikfehler in Z2: das soll wohl a.event_id=b.event_id
heißen.

Zergling-new · 05.08.2006, 18:49

Zitat:

Zitat von xabbuh

Mal eine allgemeine Frage: Warum vergibst du überhaupt Flags, um einen Benutzer als "fest gebucht", "Nachrücker" etc. zu kennzeichnen? Wäre es für dein Script nicht möglicherweise ausreichend, anhand der Reihenfolge der Eintragszeit zu ermitteln, ob ein Benutzer noch innerhalb des zur Verfügung stehenden Kontingent liegt oder nicht?

Das wäre jetzt auch mein Vorschlag gewesen, denn

Zitat:

Zitat von tinchen

Leider geht das nicht, da es in Wirklichkeit noch sehr viel komplexer ist.

je komplexer das System, desto einfacher* solltest du dein Code- und Datenbank-Layout halten. Einfacher im Sinne von weniger Algorithmen und direkten Status-Änderungen zu einem Zeitpunkt oder bei einem bestimmten Ereignis.

Der Vorschlag von xabbuh ist in sofern schon der beste. Vielleicht erklärst du uns mal genauer, worum es sich bei deinem Projekt handelt.

Ansonsten versuch so viel wie möglich zu kapseln, also deine Algorithmen hinter einfachen Klassen-Methoden oder Funktionen zu verstecken und denk daran, dass eine Funktion im allgemeinen nicht mehr als 20 (!) Zeilen Code beinhalten sollte. Alles was darüber hinausgeht, sollte in andere Funktionen ausgelagert werden.

Dein Code sieht nämlich kompliziert aus, obwohl ich das Problem (~ beschränkte Event-Zuordnung mit Nachrückerliste) eigentlich für nicht soo kompliziert halte.

tinchen · 06.08.2006, 20:19

Es handelt sich hierbei um ein Buchungssystem, das Usern erlaubt Buchungen vorzunehmen. Dabei ist die Anzahl der möglichen Buchungen pro Event wechselnd. Bei der Buchung selbst gibt es Stadien:
vorläufig gebucht,
fest gebucht,
und Nachrücker

User müssen in einem Zeitfenster von zwei Wochen vor dem Eventbegin ihre Teilnahme noch einmal bestätigen. Wird die Teinahme nicht bestätigt fliegt der User aus der Liste und die nächste Person aus der Nachrückerliste rückt nach, der seine Teilnahme kurzfristig auch noch einmal bestätigen muss.

Gleichzeitig können User eine gebuchte Veranstaltung löschen. Wird gelöscht können diese User diese Veranstaltung nicht noch einmal belegen.

Zudem sind nicht nur Buchungen möglich, sondern auch Merklisteneinträge, so dass der User seine Veranstaltung ähnlich wie in einem Warenkorb vorselektieren kann. Das habe ich mit einem weiteren Status versehen. Allerdings wird dabei nicht mit Sessions gearbeitet sondern mit einem Timestamp und Cronjob, der die Veranstaltung irgendwann automatisch für diese User löscht. Dabei werden Löschungen und Merkungen in der Administration aufgeführt, um ggf. auf diese User zugehen zu können, falls ein Event nicht ausreichend belegt ist.
Die Daten sind also nach da, obwohl der User sie ggf. nicht mehr einsehen kann.

Gruß
Tine

Zergling-new · 06.08.2006, 20:57

Hallo - interessante Vorlage. Wie weit bist du denn mit deinem Datenbank-Layout - offenbar schon fertig?

Ich würde die Datenbank wohl etwa so designen:
(der Einfachheit deutsche Bezeichnungen)

Code:

benutzer
id | name

buchungen
id | benutzer | event | fest_gebucht | beruecksichtigt | geloescht | eintrag (DATE)
//einen zusätzlichen Primärschlüssel für (benutzer, event) anlegen

events
event | max_teilnehmer | termin (DATE)

Ich würde dann täglich einen Cronjob laufen lassen, dieser würde checken, ob in 2 Wochen ein Event stattfindet und über die maximale Teilnehmer-Zahl herausfindet, wieviele Personen, die gebucht haben eine E-Mail bekommen, über die sie die Buchung bestätigen müssen.

Code:

.. WHERE buchungen.event = #EventID# AND buchungen.geloescht = 0 ORDER BY buchungen.eintrag DESC LIMIT 0, events.max_teilnehmer

In buchungen wird nun der Flag beruecksichtigt = 1 gesetzt.

x (zB 4) Tage vor dem Event wird dann geschaut, wieviele freie Plätze es noch gibt (max_teilnehmer minus derer, die bereits fest_gebucht (=1) haben).
All diejenigen, die beruecksichtigt = 1 und fest_gebucht = 0 haben, werden geloescht = 1 gesetzt (1 = automatisch, 2 = manuell).

Die errechnete Anzahl freier Plätze macht User glücklick, die der Bedingung

Code:

.. WHERE buchungen.event = #EventID# AND buchungen.beruecksichtigt = 0 AND buchungen.geloescht = 0 ORDER BY buchungen.eintrag DESC LIMIT 0, #freie-plätze#

entsprechen. beruecksichtigt = 2 wird gesetzt (wird nicht mehr benötigt, der Statistik halber aber gesetzt).

Einen Tag davor würde ich dann nach dem Wühltisch-Prinzip gehen. Wer zuerst kommt ma(h?)lt zuerst. Alle je Interessierten (gelöschte Buchungen (manuell oder automatisch), Merkzettel) aber erfolglosen werden darüber per Mail informiert und können sich dann sofort dafür freischalten. Am Besten noch automatisch auf der Startseite oder in der Event-Leiste einen "noch Plätze frei, sofort-buchen" Button platzieren o.ä.

Einen Nachrücker-Flag hast du somit nicht benötigt.

Aber so ein Design würde wohl sowieso jeder anders machen.
Im Moment gefällt mir mein Layout dafür aber, sehe gerade keine Schwächen.

tinchen · 06.08.2006, 22:45

Nabend,

bei deinem Design kann man grundsätzlich nicht meckern.
Ich habe wohl nicht richtig aufgepasst. Diese Statusgeschichte ist erst mit
dem Wunsch von Bestätigung hinzugekommen. Bis dahin sah das Ganze ungefähr so aus:

Code:

id | user_id | event_id | status | mail | zeitstempel [Timestamp] | ersteintrag [DATE]

Bis dahin gab es nur den Status gelöscht 1 oder 0 gebucht.

Na ja und dann hat sich das daraus entwickelt.
Ob ich nun alles noch einmal umstricke oder bei meinem Statusgeschichten
beibe oder ob sich das lohnt umzuarbeiten, muss ich noch einmal durchdenken. Es entwickelt sich ja immer weiter.

Mit dem Limit hast du mich dann auf die richtige Spur gebracht, das ist das Schlüssel für den Cronjob

.

Gruß
Tine

Basti · 07.08.2006, 01:23

Hi.

Ich würde, glaube ich, eher so rangehen, die einzelnen Aktionen in der Datenbank zu dokumentieren und den Status daraus quasi dynamisch entnehmen.

Mögliche Aktionen wären dabei folgende:
- vorgemerkt
- vorläufig eingetragen
- Einladung zugemailt
- gebucht
- Buchung gelöscht

Jede Aktion wird natürlich dem Benutzer und dem Buchungsobjekt zugeordnet und mit der Zeit versehen, zu der die Aktion ausgeführt wurde.

Damit hast du den kompletten Verlauf dokumentiert und damit ein Maximum an Information. Auch kannst den Workflow im laufenden Betrieb ändern, beliebige Aktionen hinzufügen (z.B. Absage, zweite Einladungsmail, Zahlungseingang) und bist von dieser großen Anzahl an Stati (gibt ja einige Kombinationsmöglichkeiten) weg.

Datensätze für vergangene Veranstaltungen kannst du in eine Archiv-Tabelle kopieren (so oder so).

Basti

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Cronjob: Falsche Ausführung - CPU schuld?	Curanai	Server, Hosting und Workstations	1	18.10.2007 19:11
Variablen in Query automatisch escapen	Maho88	PHP Tipps 2007	10	31.07.2007 08:42
php cronjob erstellt keine txt-datei...	MrCavity	Server, Hosting und Workstations	1	14.10.2006 15:57
PHP/MySQL: Query wird nicht ausgeführt	Zergling-new	Tutorials	5	09.05.2006 23:16
[Erledigt] Cronjob mit sehr kleinem Zeitintervall		PHP-Fortgeschrittene	8	25.03.2006 23:05
query rï¿½cksetzen?	Promaetheus	PHP Tipps 2007	15	01.12.2005 13:53
Query, was aus einer Tabelle mehrere Summen rausholt		Datenbanken	3	14.09.2005 16:45
Geht das mit nur einem Query?	Bouni	Datenbanken	3	14.09.2005 09:08
problem bei exec(tar ...) ausführen über cronjob		PHP-Fortgeschrittene	2	06.07.2005 10:58
verschachtelte MySQL-Abfrage		PHP Tipps 2005	3	04.05.2005 12:44
My SQL Abfrage & Ausführung per Cronjob		PHP Tipps 2005	1	23.04.2005 16:08
mysql query fehler		Datenbanken	6	19.01.2005 23:44
mysql update query mit mehreren Tabellen funktioniert nicht		PHP-Fortgeschrittene	5	08.01.2005 16:29
select query durch if anweisungen splitten		Datenbanken	6	06.09.2004 13:46
[Erledigt] Query läuft nicht		Datenbanken	6	13.08.2004 21:13

04.08.2006, 21:52
tinchen Erfahrener Benutzer Registriert seit: 16.02.2006 Beiträge: 303	verschachtelte query für Cronjob Nabend zusammen, ich habe wieder mal eine Vielzahl von Möglichkeiten durchprobiert (Joins, mehrere foreach Geschichten, ...) aber nichts von dem erfüllt das, was ich möchte. Ich möchte einen Cronjob zu einer bestimmten Zeit, als auch bei einer bestimmten Aktion ausführen. In einer Datenbanktalle werden User mit einer bestimmten Eigenschaft (status) zu einem event zugeordnet. Um ein Beispiel zu nennen: user_id \| event_id \| status \| zeitstempel 1 \| 23 \| 1 \| 2006-08-04 19:37:02 2 \| 23 \| 1 \| 2006-08-04 19:37:22 3 \| 23 \| 2 \| 2006-08-04 19:37:32 Der Status 1 bedeutet letztendlich das die Person diesen Event fest gebucht hat, bei Status 2 befindet er sich auf der Nachrückerliste, weil die Veranstaltung z.B. nur für 2 Personen ausgelegt ist. Die Daten werden bereits geschrieben, lassen sich verwalten und löschen. Löscht der User 2 seine Belegung soll User 3 automatisch nachrücken. Dieses soll bei der Aktion des Löschens und zur Sicherheit noch einmal per Cronjob ausgeführt werden. Die Anzahl der Plätze findet sich in einer anderen Tabelle. event_id \| free_places \| .... 23 \| 2 \| ... Wie mache ich das am besten von der Idee her? Gruß Tine


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

04.08.2006, 22:35
xabbuh Erfahrener Benutzer Registriert seit: 13.11.2005 Beiträge: 2.583	Mal eine allgemeine Frage: Warum vergibst du überhaupt Flags, um einen Benutzer als "fest gebucht", "Nachrücker" etc. zu kennzeichnen? Wäre es für dein Script nicht möglicherweise ausreichend, anhand der Reihenfolge der Eintragszeit zu ermitteln, ob ein Benutzer noch innerhalb des zur Verfügung stehenden Kontingent liegt oder nicht? Wenn du nun trotzdem bei deinem Weg bleiben möchtest, solltest du dir - MySQL 5.0 oder höher vorrausgesetzt - in der MySQL-Dokumentation das Kapitel über Trigger ansehen: http://dev.mysql.com/doc/refman/5.0/en/triggers.html

04.08.2006, 23:31
tinchen Erfahrener Benutzer Registriert seit: 16.02.2006 Beiträge: 303	Leider geht das nicht, da es in Wirklichkeit noch sehr viel komplexer ist. Es gibt Bestätigungen, Zurückmeldungen in bestimmten Zeiträumen etc. Es gibt derzeit 5 verschiede Möglichkeiten den Status zu beschreiben. MySQL bewegt es sich derzeit in 4.1.12. Meine ersten Ideen sehen so oder so ähnlich aus, allerdings nicht wirklich zu gebrauchen. PHP-Code: $query = "SELECT distinct(a.event_id), a.v_free FROM jos_skiba_veranstaltungen AS a INNER JOIN jos_skiba_buchung AS b ON b.event_id=b.event_id ORDER BY b.zeitstempel ASC" ; $database->setQuery( $query ); $rows = $database->loadObjectList(); foreach ( $rows as $row ) { $query = "SELECT count(status) FROM jos_skiba_buchung WHERE event_id=$row->event_id AND (status=1 OR status=5)" ; $database->setQuery( $query ); $total_bookings = $database->loadResult(); $query = "SELECT count(status) FROM jos_skiba_buchung WHERE event_id=$row->event_id AND (status=3)" ; $database->setQuery( $query ); $statuscheck = $database->loadResult(); if($total_bookings<$row->v_free && $statuscheck) { $query = "UPDATE jos_skiba_buchung SET status=1 WHERE status=3 AND event_id=$row->event_id"; $database->setQuery($query); $database->query(); } } Geht nur teilweise, wenn die Bedingung erfüllt ist, bekommen alle User den Status 1 zugewiesen. Also so geht es nicht wirklich. Gruß Tine

05.08.2006, 16:42
pepe24 Erfahrener Benutzer Registriert seit: 21.07.2005 Beiträge: 209	Leider ist es schwer, nachzuvollziehen, was Du da genau tust. Kommentare sind dazu einfach unumgänglich! Kannst Du das <select> statement in der foreach schleife nicht umgehen? Außerdem ist da ein semantikfehler in Z2: das soll wohl a.event_id=b.event_id heißen.

06.08.2006, 20:19
tinchen Erfahrener Benutzer Registriert seit: 16.02.2006 Beiträge: 303	Es handelt sich hierbei um ein Buchungssystem, das Usern erlaubt Buchungen vorzunehmen. Dabei ist die Anzahl der möglichen Buchungen pro Event wechselnd. Bei der Buchung selbst gibt es Stadien: vorläufig gebucht, fest gebucht, und Nachrücker User müssen in einem Zeitfenster von zwei Wochen vor dem Eventbegin ihre Teilnahme noch einmal bestätigen. Wird die Teinahme nicht bestätigt fliegt der User aus der Liste und die nächste Person aus der Nachrückerliste rückt nach, der seine Teilnahme kurzfristig auch noch einmal bestätigen muss. Gleichzeitig können User eine gebuchte Veranstaltung löschen. Wird gelöscht können diese User diese Veranstaltung nicht noch einmal belegen. Zudem sind nicht nur Buchungen möglich, sondern auch Merklisteneinträge, so dass der User seine Veranstaltung ähnlich wie in einem Warenkorb vorselektieren kann. Das habe ich mit einem weiteren Status versehen. Allerdings wird dabei nicht mit Sessions gearbeitet sondern mit einem Timestamp und Cronjob, der die Veranstaltung irgendwann automatisch für diese User löscht. Dabei werden Löschungen und Merkungen in der Administration aufgeführt, um ggf. auf diese User zugehen zu können, falls ein Event nicht ausreichend belegt ist. Die Daten sind also nach da, obwohl der User sie ggf. nicht mehr einsehen kann. Gruß Tine

06.08.2006, 20:57
Zergling-new Erfahrener Benutzer Registriert seit: 21.05.2008 Beiträge: 9.937	Hallo - interessante Vorlage. Wie weit bist du denn mit deinem Datenbank-Layout - offenbar schon fertig? Ich würde die Datenbank wohl etwa so designen: (der Einfachheit deutsche Bezeichnungen) Code: benutzer id \| name buchungen id \| benutzer \| event \| fest_gebucht \| beruecksichtigt \| geloescht \| eintrag (DATE) //einen zusätzlichen Primärschlüssel für (benutzer, event) anlegen events event \| max_teilnehmer \| termin (DATE) Ich würde dann täglich einen Cronjob laufen lassen, dieser würde checken, ob in 2 Wochen ein Event stattfindet und über die maximale Teilnehmer-Zahl herausfindet, wieviele Personen, die gebucht haben eine E-Mail bekommen, über die sie die Buchung bestätigen müssen. Code: .. WHERE buchungen.event = #EventID# AND buchungen.geloescht = 0 ORDER BY buchungen.eintrag DESC LIMIT 0, events.max_teilnehmer In buchungen wird nun der Flag beruecksichtigt = 1 gesetzt. x (zB 4) Tage vor dem Event wird dann geschaut, wieviele freie Plätze es noch gibt (max_teilnehmer minus derer, die bereits fest_gebucht (=1) haben). All diejenigen, die beruecksichtigt = 1 und fest_gebucht = 0 haben, werden geloescht = 1 gesetzt (1 = automatisch, 2 = manuell). Die errechnete Anzahl freier Plätze macht User glücklick, die der Bedingung Code: .. WHERE buchungen.event = #EventID# AND buchungen.beruecksichtigt = 0 AND buchungen.geloescht = 0 ORDER BY buchungen.eintrag DESC LIMIT 0, #freie-plätze# entsprechen. beruecksichtigt = 2 wird gesetzt (wird nicht mehr benötigt, der Statistik halber aber gesetzt). Einen Tag davor würde ich dann nach dem Wühltisch-Prinzip gehen. Wer zuerst kommt ma(h?)lt zuerst. Alle je Interessierten (gelöschte Buchungen (manuell oder automatisch), Merkzettel) aber erfolglosen werden darüber per Mail informiert und können sich dann sofort dafür freischalten. Am Besten noch automatisch auf der Startseite oder in der Event-Leiste einen "noch Plätze frei, sofort-buchen" Button platzieren o.ä. Einen Nachrücker-Flag hast du somit nicht benötigt. Aber so ein Design würde wohl sowieso jeder anders machen. Im Moment gefällt mir mein Layout dafür aber, sehe gerade keine Schwächen.

06.08.2006, 22:45
tinchen Erfahrener Benutzer Registriert seit: 16.02.2006 Beiträge: 303	Nabend, bei deinem Design kann man grundsätzlich nicht meckern. Ich habe wohl nicht richtig aufgepasst. Diese Statusgeschichte ist erst mit dem Wunsch von Bestätigung hinzugekommen. Bis dahin sah das Ganze ungefähr so aus: Code: id \| user_id \| event_id \| status \| mail \| zeitstempel [Timestamp] \| ersteintrag [DATE] Bis dahin gab es nur den Status gelöscht 1 oder 0 gebucht. Na ja und dann hat sich das daraus entwickelt. Ob ich nun alles noch einmal umstricke oder bei meinem Statusgeschichten beibe oder ob sich das lohnt umzuarbeiten, muss ich noch einmal durchdenken. Es entwickelt sich ja immer weiter. Mit dem Limit hast du mich dann auf die richtige Spur gebracht, das ist das Schlüssel für den Cronjob . Gruß Tine

07.08.2006, 01:23
Basti Erfahrener Benutzer Registriert seit: 18.07.2004 Beiträge: 2.162 PHP-Kenntnisse: Fortgeschritten	Hi. Ich würde, glaube ich, eher so rangehen, die einzelnen Aktionen in der Datenbank zu dokumentieren und den Status daraus quasi dynamisch entnehmen. Mögliche Aktionen wären dabei folgende: - vorgemerkt - vorläufig eingetragen - Einladung zugemailt - gebucht - Buchung gelöscht Jede Aktion wird natürlich dem Benutzer und dem Buchungsobjekt zugeordnet und mit der Zeit versehen, zu der die Aktion ausgeführt wurde. Damit hast du den kompletten Verlauf dokumentiert und damit ein Maximum an Information. Auch kannst den Workflow im laufenden Betrieb ändern, beliebige Aktionen hinzufügen (z.B. Absage, zweite Einladungsmail, Zahlungseingang) und bist von dieser großen Anzahl an Stati (gibt ja einige Kombinationsmöglichkeiten) weg. Datensätze für vergangene Veranstaltungen kannst du in eine Archiv-Tabelle kopieren (so oder so). Basti