Support-Forum Mirko Böer Softwareentwicklungen

MarcusK hat geschrieben:

mirko hat geschrieben: Ich habe für MySQL 4.05 die Doku hier auf meinem Rechner, damit ich keine Funktionen verwende, die es im alten MySQL noch nicht gab, kann die Funktion auch nicht drin sein. Aber 1024 kann halt nicht genug sein, man weiss das nicht vorher, außer man macht vorher wieder ne Abfrage nach allen Gruppennamen, hängt die zusammen, bekommt die Länge, setzt den Wert und macht dann die Abfrage. Das spart aber wahrscheinlich am Ende nichts.

Ich denke, MySQL 4.05 ist nicht mehr zeitgemäß. Ein Export mit Gruppeninfo ist aber auch keine Funktion, die so essentiell ist, wie das Versenden des Newsletters. Es wäre daher kein Problem, wenn es diese Funktion nur gibt, wenn man mindestens SQL 4.1 (eigentlich auch nicht mehr zeitgemäß) einsetzt.
Du kannst group_concat_max_len doch von Haus aus auf max_allowed_packet setzen. Dann sparst du dir die Abfage. Die Länge der Gruppennamen lässt sich außerdem mit einem einfach Sub-Select-SQL-Befehl ermitteln (Ich habe jetzt nicht die genaue MySQL-Syntax nachgesehen, aber ich denke es wird klar, was ich meine).

Code: Alles auswählen

SELECT sum(GroupnameLength) from (SELECT Len(Groupname) as GroupnameLength FROM Newelsttergroups ) as tmp ) 

Mirko hat geschrieben: Ich verwende es zumindest nicht, die Gruppennamen getrennt mit Komma, Semikolon, der nächste vielleicht mit Bindestrich und der übernächste mit <li> davor, wird es im Newslettertext nicht geben, weil es halt wieder das Trennzeichen-Problem ist, jeder will es gern anders haben.

Genau, das ist es ja! Jeder möchte es anders haben und braucht es aus einem bestimmten Grund vielleicht auch. Statt künstlich viele Einschränkungen zu machen, wäre eine saubere Trennung der Displayschicht von der Adminschicht die richtige Lösung. Dann kann jeder machen, was er will und es müssen keine Posts geschrieben werden . Satt die Displayschicht in der Gruppendefinition festzulegen, wäre es evtl. sogar noch sinnvoller diese bei der Anzeige (Form, Newsletter) definieren zu können. Dann könnte man verschieden Ausgaben (HTML, Newsetter HTML, Newsletter Text) definieren, also so 'ne Art Mediaquery, wie bei CSS. (man darf ja wohl spinnen und träumen dürfen )

Mirko hat geschrieben: Ja aber es versteht nicht jeder. Der unbedarfte Nutzer in der Marketing-Abteilung hat keine Ahnung wovon ich da rede, der will sich damit auch gar nicht beschäftigen, das ist nicht seine Aufgabe, der will einfach nur das es funktioniert.

Das ist absolut richtig! Der unbedarfte Nutzer aus der Marketing-Abteilung hat wirklich keine Ahnung, wenn er sich nicht ausgiebig damit beschäftigt. Das eigentliche Problem ist, dass ein Server-Newsletter-System mit verschiedenen nicht-standardisierten Clients, sich ständig ändernden gesetzlichen Bestimmungen, etc. nicht einfach ist. Der grundlegende Fehler ist es, jemanden das als einfach zu verkaufen. Ich weiß, dass wird bei allen Computerprogrammen gemacht. Die Sachen sind aber i.d.R. (noch) nicht so einfach, dass sie jeder einfach so kann. Alleine einen HTML-Newsletter zu erzeugen, der auch auf den wichtigsten Clients angezeigt werden kann ist eine Wissenschaft für sich. Das hat mich als versierten Computler zwei Wochen Zeit gekostet. Wie soll das ein Marketing-Angestellter machen, wenn er kein HTML versteht? SWM ist ein Wekrzeut, dessen Umgang man lernen muss.

Ich finde, jeder Schritt, der ein Programm einfacher in der Bedienung macht ist ein guter und wichtiger Schritt. Es spart Zeit, mindert Frust und hilft die Arbeit rechtzeitig fertig zu bekommen. Aber, dass man ein Newsletter-System und einen Newsletter einfach mal so machen kann, ist definitv nicht richtig. Dazu ist dasthema generell zu komplex.

Eine Funktion, wie ein Export mit Gruppenzugehörigkeiten oder die Möglichkeit, Gruppeninfos in einem Newsletter anzuzeigen, würde nicht nur dem NL-Administrator das Leben leichter machen (alleine das einfache Backup aller Daten ist schon viel wert), sondern auch dem Endkunden würde es den Umgang mit dem Newsletter (An-/Abmedlung, etc.) leichter machen. Ich bin überzeugt, dass die Remove-Rate nach einem Newsletterversand geringer ausfallen würde, wenn der Kunde seine Gruppen sehen würde und sich damit gegebenenfalls von einzelnen Gruppen abmelden könnte, statt sich gleich generell abmeldet. Anzeigmöglichkeiten von Gruppen sind daher eine wichtige Sache, um den Grundzweck eines NL-Systems zu verbessern.

mirko hat geschrieben: Ich habe für MySQL 4.05 die Doku hier auf meinem Rechner, damit ich keine Funktionen verwende, die es im alten MySQL noch nicht gab, kann die Funktion auch nicht drin sein. Aber 1024 kann halt nicht genug sein, man weiss das nicht vorher, außer man macht vorher wieder ne Abfrage nach allen Gruppennamen, hängt die zusammen, bekommt die Länge, setzt den Wert und macht dann die Abfrage. Das spart aber wahrscheinlich am Ende nichts.

SELECT sum(GroupnameLength) from (SELECT Len(Groupname) as GroupnameLength FROM Newelsttergroups ) as tmp ) 

Mirko hat geschrieben: Ich verwende es zumindest nicht, die Gruppennamen getrennt mit Komma, Semikolon, der nächste vielleicht mit Bindestrich und der übernächste mit <li> davor, wird es im Newslettertext nicht geben, weil es halt wieder das Trennzeichen-Problem ist, jeder will es gern anders haben.

Mirko hat geschrieben: Ja aber es versteht nicht jeder. Der unbedarfte Nutzer in der Marketing-Abteilung hat keine Ahnung wovon ich da rede, der will sich damit auch gar nicht beschäftigen, das ist nicht seine Aufgabe, der will einfach nur das es funktioniert.

Marcus hat geschrieben: Würde denn mein Trick die Kommas als &#44; zu schreiben funktionieren (Trennzeichen zwischen Spalten muss dann natürlich ein Tabulator sein)?

Mirko hat geschrieben: Ja.

MarcusK hat geschrieben:Hallo Mirko,

Group_concat gibt es in MYSQL ab Version 4.1(.6). 1024 ist nur die Default-Größe:

The result is truncated to the maximum length that is given by the group_concat_max_len system variable, which has a default value of 1024. The value can be set higher, although the effective maximum length of the return value is constrained by the value of max_allowed_packet.

Ich nutze selbst i.d.R MS SQL Server. Der hat leider keiner Group_Concat Funktion, aber ich habe eine entsprechende User Defined Function erstellt, mit der ich das gleiche Ergebnis bekomme. Codebeispiele gibt es viele im Internet. Man kann also auch ohne Group_Concat eine kommegetrennte Liste erzeugen. Mit Group_Concat ist es nur viel einfacher und auch etwas schneller.

Die ? sind sehr gut. Das ist ja auch eine Dokumentation. Solange der User über die Seiteneffekte und vor allem das Warum aufgeklärt wird, kann er auch was Vernünftiges und dann auch mit hoher Wahrscheinlichkeit das Gewollte anstellen.

Bei SWM hat der Gruppenname zwei Funktionen. Er ist der Displayname und zugleich der Name, um die Gruppe im Admintool anzusprechen (Empfängerauswahl, Import). Die drei Layer (DB, Businesslogik und Display) werden hier zu zwei verbunden und der Businesslogikname hat auch die Funktion des Displaynamens. Deshalb gibt es auch die Kommaprobleme. Intern im DB-Layer werden ja IDs verwendet werden. Es wäre einfacher und problemloser, wenn man in der Adminschicht ein Gruppennamenkürzel hätte. Dann könnte man im Admintool und damit auch beim Importieren kurze Namen ohne Komma oder Sonderzeichen verwenden und für das Display auf der Website einen Displaynamen definieren, der auch Kommas, Zeilenumbrüche etc. enthalten kann (die Displayschicht hat andere Einschränkungen und Codes als die Adminschicht): Z.B. Admin-Gruppenname: MBSW, Displayname: Müncher „Balboa“, „Bal-Swing“ und „Shag“ Wochenende.

Würde denn mein Trick die Kommas als &#44; zu schreiben funktionieren (Trennzeichen zwischen Spalten muss dann natürlich ein Tabulator sein)?

The result is truncated to the maximum length that is given by the group_concat_max_len system variable, which has a default value of 1024. The value can be set higher, although the effective maximum length of the return value is constrained by the value of max_allowed_packet.

Seit wann sind den keine Kommas mehr im Gruppennamen erlaubt? Was meinst du mit "Man kann nämlich die Gruppen mit RG=gruppename1,gruppename2 dem Script nl.php übergeben"? Ich habe das nicht wirklich verstanden. Ich vermute, dass es bedeutet, dass mehrere unserer Newsletter überhaupt nicht zugestellt wurden, weil die ausgewählten Gruppen nicht erkannt wurden? Die Kommas sind bei uns schon in den Gruppennamen seitdem ich die Mailingliste vor über einem Jahr angelegt hatte.

Generell kann ich deiner Aussage, dass SWM schon zu viele Einstellungsmöglichkeiten hat und deshalb keiner mehr hinzugefügt werden sollen nicht zustimmen. Eien Software soll das können, was man damit machen muss. Es ist für mich immer im wesentlichen eine Frage der Strukturierung der Optionen und vor allem der Dokumentation. Bei einer guten Dokumentation kann man sich auch als unbedarfter Anwender zurecht finden, weil man dann weiß wofür man eine Einstellung benötigt. Eine Eingabe des Trennzeichens für die Gruppennamen hätte sicher niemanden abgehalten, SWM einzusetzen. Man kann das Feld ja auch erst dann sichtbar machen, wenn man die Gruppenoption wählt. Hier wurde ein tolles Feature nur nicht konsequent implementiert.

Nachdem du aber kein Feld hinzufügen willst und die Gruppennamen nun wirklich beknackt aussehen, könntest du dich erwärmen, für die Gruppennamen eine Displayoption hinzuzufügen? Also z.B. Gruppenname: MBSW, Displayname: "Müncher Balboa, Bal-Swing und Shag Wochenende". Dann kann man bequem intern und zum Importieren mit kurzen Namen arbeiten und für die Ausgabe in den Formularen beliebige Sonderzeichen und vor allem auch Kommas verwenden.

In dem Footer kannst vergessen, da leiten alle unter Performance-Problemen, nur weil du so eine Funktion willst. Er muss nämlich dann pro Empfänger bei der E-Mail-Erstellung noch eine zusätzliche SQL-Anweisung mit diversen JOINS an den Server senden, um die Gruppenzugehörigkeiten und Namen der Gruppen zu bestimmen. Beim Export ist es genauso, er muss wieder eine zusätzliche SQL-Anweisung verwenden, um Gruppenzugehörigkeiten und Namen zu bestimmen.

Das verstehe ich nicht. Für was brauchst du diverse JOINS? Die Backengine ist doch MySQL, da kannst du doch in einer SQL-Anweisung mit GROUP_CONCAT
für alle Empfänger die Liste ihrer Gruppen erzeugen:

SELECT m.id, GROUP_CONCAT(g.groupname) AS group_list
FROM mailinglist m
INNER JOIN groups g ON(m.id = g.id)
GROUP BY g.id;

Hier wird für jeden Eintrag die mit Komma getrennte Liste der Gruppen erzeugt. Ein Statement für alle Empfänger. Das wird performant auf dem SQL Server abgearbeitet. Mit Admin-Zugriff und grundlegenden SQL-Kenntnissen auf die DB kann man das ja sogar selber abschicken. Schöner wäre das aber schon aus der SWM-Admin Page heraus. Generell sind gut geschriebene SQL statements mit passenden Indizes selten das Bottleneck bei der Performance.

Wir hatten uns schon mal über die Performance unterhalten. Generell denke ich, wäre es besser, wenn du die E-Mails parsen würdest und nur die Felder von der DB abfrägst, die auch wirklich benötigt werden, als immer die gesamte Tabelle abzufragen. Das kann im Extremfall bei vielen gefüllten Feldern und eienr sehr großen Mailingliste einen erheblichen Unterschied in der Performance ausmachen.

mirko hat geschrieben:das musst du 2x gepostet haben, ich hatte 2 E-Mails bekommen, bei der einen kam Beitrag nicht gefunden, da habe ich dann den 2. Eintrag auch nicht beachtet.

Die Sache mit dem Komma oder Semikolon im Gruppennamen ist ein Kompromiss für Profis gewesen, ich kann nicht überall noch mehr Eingabefelder einbauen, der Normalnutzer sieht einfach nicht mehr durch wofür das alles so gedacht ist. Und Kommas im Gruppennamen dürfen nicht vorkommen, das muss ich ändern, eindeutig ein Bug, habe ich nicht abgefangen. Man kann nämlich die Gruppen mit RG=gruppename1,gruppename2 dem Script nl.php übergeben, damit werden deine Gruppennamen mit Komma überhaupt nicht erkannt, das geht voll schief.

In dem Footer kannst vergessen, da leiten alle unter Performance-Problemen, nur weil du so eine Funktion willst. Er muss nämlich dann pro Empfänger bei der E-Mail-Erstellung noch eine zusätzliche SQL-Anweisung mit diversen JOINS an den Server senden, um die Gruppenzugehörigkeiten und Namen der Gruppen zu bestimmen. Beim Export ist es genauso, er muss wieder eine zusätzliche SQL-Anweisung verwenden, um Gruppenzugehörigkeiten und Namen zu bestimmen.

MarcusK hat geschrieben: Gibt es in der Zwschenzeit - bis du *hoffentlich* diese Erweiterung implementieren wirst - einen Workaround? Kann man das Komma im Gruppennamen beim Import irgendwie escapen? Ich habe auch versucht, die Gruppennamen in Anführungszeichen zu schreiben, das funktioniert aber auch nicht.

MarcusK hat geschrieben: Ich hatte auch die Idee im Gruppennamen statt den Kommas &#44; zu schreiben. Diese würden zwar in SWM komisch aussehen, aber in allen Web-Formularen müssten sie richtig angezeigt werden. Allerdings kann ich den Gruppennamen nicht ändern nur löschen und neu hinzufügen, was aber die Gruppenzugehörigkeit ebenfalls löscht. Da man ja die Gruppeninfos nicht exportieren kann, kann ich sie auch nicht wieder herstellen. Arggg!

MarcusK hat geschrieben: Im Moment sehe ich daher nur noch die Möglichkeit, wieder auf die alte umständliche und zeitraubende Weise für unsere 7 Gruppen sieben einzelne Importlisten zu generieren und diese einzeln einzufügen. Ahhhhh! Ich nutze aber inzwischen die Double-Opt-In Option beim Import. Deshalb meine Frage: Ist es richtig, dass der importierte Empfänger nur beim erstemaligen Eintrag in die Liste eine Bestätigungs-E-Mail erhält? Wird in einem zusätzlichen Importschritt eine weitere Gruppe hinzugefügt, bekommt der Empfänger keine weitere Bestätigung, oder?

MarcusK hat geschrieben: Ein Forumteilnehmer hatte sich den Export von Gruppeninformationen gewünscht - genaus so wie den Import. Dies würde ich auch unterstützen!
Außerdem wünsche ich mir auch eine Möglichkeit auf die Gruppeninformationen in den E-Mails zuzugreifen. Ich möchte gern, dass ich im Footer meiner Newsletter für jeden Teilnehmer anzeigen kann, welchen Gruppe er ausgewählt hat. Ebenso wäre diese Information im Bestätigungs-E-Mail an den Kunden bzw. an den Admin gewünscht.