MySQL: Tabellenstruktur für einen Life-Cycle-Mailer

suntrop

Erfahrenes Mitglied
Hallo

Ich stehe vor der Aufgabe einen Life-cycle-Mailer* zu erstellen.
Ich habe auch einen Lösungsweg im Kopf und auf Papier. Aber ist der Weg auch gut? Oder wenig performant oder ineffizient?

So sieht (ganz grob gesehen :) ) die Tabellenstruktur aus:
pic_Zcd_l.jpg


Für jede einzelne E-Mail wird in der Sendeliste ein Eintrag erstellt. Das Sendescript (PHP) prüft mehrmals täglich, ob der Zeitpunkt in der Vergangenheit liegt und wenn ja, dann wird diese E-Mail an diesen Empfänger gesendet und der Eintrag gelöscht. Im Anschluss muss der Eintrag für die nächste E-Mail erstellt werden (die Info werde ich wohl aus einer zusätzlichen 'Optionen' Tabelle holen).

Bin ich da auf dem richtigen Weg? :)

Würde mich über ein paar Meinungen freuen.
Danke und Grüße
- suntrop -


*
Kurz gesagt ein PHP-Newsletter-Programm, das aber nicht konventionell einmal an eine Empfängerliste eine E-Mail sendet, sondern zu unterschiedlichen Zeitpunkten vordefinierte E-Mails an unterschiedliche Empfänger.
Zum Beispiel an einen Seminarteilnehmer. Nach einer Woche erhält derjenige Mail 1 mit einer Inhaltszusammenfassung. Nach 4 Wochen die nächste E-Mail mit weiteren Infos, nach 8 Wochen die nächste E-Mail usw. Die Mails sind vordefiniert und in der DB abgespeichert.
 
Das Sendescript (PHP) prüft mehrmals täglich, ob der Zeitpunkt in der Vergangenheit
Ein Cronjob pro Tag genügt völlig. Du kannst in der Empfänger Tabelle auch einfach das Datum speichern, zu dem Zeitpunkt als der Teilnehmer das Seminar betreten hat.
In der EMails-Tabelle fügst du die Spalte Woche hinzu, damit du weißt nach wie viel Wochen die Mail gesendet wird.

Dann brauch das PHP Script einfach eine Datum-Differenz in Wochen von Heute-Eintrittsdatum erstellen und dazu die korrekte Mail senden!
 
Danke Steusi.
Den CroneJob wollte ich evtl. mehrmals tägl. ausführen, da die Mails vielleicht mal morgens, mal abends gesendet werden sollen. Hatte ich dabei vergessen zu erwähnen.

Deine Idee gefällt mir auch. Der Dreh- und Angelpunkt ist also die Empfänger-Tabelle. Das würde es glaube ich vereinfachen.
Ich lass mir das noch einmal durch den Kopf gehen. Wenn später Statistikdaten gesammelt werden sollen, dann ist der erste Weg "ausbaufähiger", oder nicht?

Hat also aus deiner Sicht mein Weg keine Schlaglöcher?

Schönen Dank und Gruß
suntrop
 
Dein Ansatz kann genauso ausgeführt werden, es kommt drauf an was du in deiner Statistik mit aufnehmen möchtest. Wenn du nur ermitteln möchtest, welche E-Mail ein Teilnehmer als letztes bekommt hat, genügen auch 2 Tabellen. In punkto Erweiterbarkeit ist dein Ansatz gut.


Code:
Empfänger
ID | EMail | Datum
1 | a@b.com | 2008-06-13
2 | b@b.com | 2008-07-30

EMail
ID | Woche | Betreff | Nachricht
1 | 0 | Anmeldung | blablub
2 | 1 | Einführung | blablub

Die Tabellen sind dann natürlich nicht mit einander verknüpft das ist korrekt, außer über die Differenz vom Datum - Woche.

Abfrage nach der letzten Mail wäre dann folgendermaßen:
SQL:
SELECT 
  E.EMail,
  M.Betreff
FROM Empfänger AS E
  INNER JOIN
  EMail AS M
  ON FLOOR(DATEDIFF(CURDATE(), E.Datum)/7) = M.Woche;
*ungetestet
 
Zuletzt bearbeitet von einem Moderator:
Zurück