MySQL kann UTF-8… falsch. Besser gesagt: Ungenau. MySQL kann UTF-8, aber das heißt da anders:
Ein Zeichen in UTF-8 ist (bis zu) vier Bytes lang, “UTF-8” in MySQL kann aber nur bis zu drei. Deswegen fällt der Unterschied oft gar nicht auf, oder erst beim ersten Zeichen, das vier Bytes braucht. Will man echtes UTF-8, muss man einiges umkonfigurieren; in Kurzform:
CHARSET=utf8mb4 COLLATE utf8mb4_unicode_ci” umgestellt werden
TINYTEXT, die wohl nur 255 Bytes = 63 Zeichen bei 4 Byte/Zeichen speichern können. Ggf. ist hier ein anderer Typ zu wählenSHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';“)|
1 2 3 |
# For each table REPAIR TABLE table_name; OPTIMIZE TABLE table_name; |
bzw.
|
1 |
mysqlcheck -u root -p --auto-repair --optimize --all-databases |
Insbesondere bei Punkt 3 hängt es bei CodeIgniter, btw. Wenn man in der Datenbank-Config
|
1 2 |
$db['default']['char_set'] = 'utf8'; $db['default']['dbcollat'] = 'utf8_unicode_ci'; |
stehen hat, dann ist das ebenfalls nicht das echte UTF-8. Stattdessen korrekt ist:
|
1 2 |
$db['default']['char_set'] = 'utf8mb4'; $db['default']['dbcollat'] = 'utf8mb4_unicode_ci'; |
Das Problem betrifft auch mysqldump: Will man die eine utf8mb4-Datenbank dumpen, muss man das explizit sagen, denn mysqldump nutzt per Default nur utf8 (Quelle):
|
1 |
mysqldump --default-character-set=utf8mb4 -u [uname] -p"[pass]" db_name > db_backup.sql |
Das ist so tief verankert, dass auch Dumps über Tools wie Sequel Pro nur utf8 nutzen m(
FPDF ist ein gutes Tool, um mit PHP recht einfach PDFs zu erstellen. Hier meine gesammelten Learnings nach der ersten Anwendung:
Und schließlich, nicht direkt zu FPDF: Wenn es UTF8-Probleme mit Texten aus der Datenbank gibt, kann es daran liegen, dass der Text nicht UTF8-kodiert aus gelesen wird. Ein
|
1 |
mysql_set_charset('utf8', $this->dbLink); |
hilft dann.
In WordPress kann man eigene Daten zu jedem Post speichern, so genannte Custom Fields. Technisch funktioniert das so, dass pro Post und Field ein Eintrag in der Tabelle wp_postmeta angelegt wird.
Beispiel: Ein Rating-Plugin könnte pro bewertetem Post einen Eintrag <meta_key:rating> mit der Gesamtzahl an “Sternen” (1=schlecht, 5=super), und einen Eintrag <meta_key:raters> mit der Anzahl an abgegebenen Stimmen anlegen. Also zwei Zeilen in wp_postmeta pro Post, für den Stimmen abgegeben wurden. Genau so macht es “Post Rate“. Anmerkung: Man speichert das schon deshalb als zwei diskrete Werte, um bei der nächsten Bewertung wieder den Durchschnitt berechnen zu können – ich musste kurz überlegen, bis mir das klar wurde 🙂
So, nun hat man in dem Beispiel bewertete Posts, und möchte diese Posts vielleicht nach ihrer Bewertung sortiert anzeigen. Kann ja nicht so schwer sein, schließlich gibt es zB $wpdb mit get_results(). Zu einem Problem wird das (für jemanden, dessen SQL-Kenntnisse etwas eingerostet sind mich) dadurch, dass es eben zwei Einträge in wp_postmeta gibt – und beide speichern ihren Wert in wp_postmeta.meta_value! Für eine Sortierung müsste man die Bewertung (stehen unter <meta_key:rating> in meta_value) durch die Anzahl an Stimmen (stehen unter <meta_key:raters> in meta_value) teilen.
Lösung: JOIN. Erst habe ich einen LEFT JOIN versucht geklaut, aber der definiert sich so, dass er alle Posts ausgegeben hätte, selbst wenn für sie gar kein Rating abgegeben wurde. Deshalb also nur JOIN. Basierend auf dem Foreneintrag mit dem LEFT JOIN ist dabei folgendes entstanden:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$querystr = "SELECT * FROM $wpdb->posts JOIN $wpdb->postmeta AS rating ON( $wpdb->posts.ID = rating.post_id AND rating.meta_key = 'rating' ) JOIN $wpdb->postmeta AS raters ON( $wpdb->posts.ID = raters.post_id AND raters.meta_key = 'raters' ) WHERE $wpdb->posts.post_status = 'publish' AND $wpdb->posts.post_type = 'post' AND $wpdb->posts.post_date < NOW() ORDER BY ((rating.meta_value)/(raters.meta_value)) DESC"; $pageposts = $wpdb->get_results($querystr, OBJECT); |
Etwas wie AS lag mir schon auf der Zunge, allerdings eher als SELECT AS… das in einem (bzw. zwei) JOIN zu verwenden, und zwar sowohl in dem JOIN (“rating.post_id”), wie auch im ORDER BY hätte ich nicht hinbekommen. In diesem Sinne: HTH 🙂
PS: Die formatierte Ausgabe ergibt sich dann aus dem bereits erwähnten Eintrag.
Normalerweise sortiert man Datensätze alphabetisch oder numerisch oder so. Will man eine bestimmte Gruppe von Datensätzen (z.B. alle mit category 4) ganz oben sehen (statt an vierter Stelle), so nutze man CASE:
|
1 |
ORDER BY CASE WHEN category=4 THEN 1 ELSE 2 END |
Das Ganze macht, dass die Datensätze in zwei Kategorien eingeteilt werden, nämlich “1” und “2”. Nach diesen wird (vor-)sortiert, jede weitere Sortierung erfolgt dann innerhalb dieser Kategorien.
HTH