Wenn Sie benutzerdefinierte Feldwerte bisher nur in wp_postmeta gespeichert haben, mussten Sie nie einen Spaltentyp wählen, denn es gibt nur einen: LONGTEXT. Alles – ein Preis, ein Datum, eine Checkbox, ein Absatz – wird als String gespeichert und beim Lesen wieder in etwas Brauchbares umgewandelt. Das funktioniert, verlagert aber die Verantwortung für die Korrektheit dauerhaft auf jeden Code, der den Wert liest.
Sobald Feldwerte in einer echten Tabelle liegen, hat jedes Feld einen Typ, und dieser Typ beeinflusst Speichergröße, Sortierverhalten und das, was die Datenbank für Sie validieren kann. Dies ist ein praktischer Leitfaden für die Wahl, geschrieben für Menschen, die sich mit WordPress auskennen, aber nicht unbedingt schon einmal ein Datenbankschema entworfen haben.
Zahlen: INT oder DECIMAL
Ganze Zahlen – ein Lagerbestand, ein Alter, eine Menge – gehören in einen Integer-Typ. Hier gibt es nur die Größe zu entscheiden: Wählen Sie einen Wertebereich, der für die erwarteten Werte ausreicht, ohne ihn „für alle Fälle“ unnötig groß zu machen.
Geldbeträge und alles mit einer festen Anzahl von Dezimalstellen sind ein anderer Fall – und einer der häufigsten Fehler im Datenbankdesign überhaupt, nicht nur bei WordPress. Gleitkommatypen (FLOAT, DOUBLE) speichern eine Näherung einer Dezimalzahl, und diese Näherung kann beim Addieren oder Vergleichen kleine Rundungsfehler verursachen. DECIMAL(10,2) speichert dagegen einen exakten Wert mit fester Stellenzahl vor und nach dem Dezimalpunkt – in diesem Beispiel insgesamt zehn Stellen, zwei davon nach dem Punkt – und ist der richtige Typ für Preise, Summen und alles andere, bei dem „ungefähr richtig“ nicht genügt.
In Mass Custom Fields verwendet ein Number-Feld standardmäßig DECIMAL(20,6): bis zu 14 Stellen vor und 6 nach dem Dezimalpunkt. In den SQL-Spaltenoptionen des Felds können Sie INT, BIGINT, TINYINT, SMALLINT, MEDIUMINT, FLOAT, DOUBLE oder ein anderes DECIMAL(p,s) wählen, etwa DECIMAL(10,2) für einen Preis. Ein Wert außerhalb des Spaltenbereichs wird auf den nächsten erlaubten Wert begrenzt, statt einen Datenbankfehler auszulösen, und eine Spalte für ganze Zahlen rundet 12.7 auf 13. Die Details stehen in der Referenz zu Zahlen und Wertebereichen.
SELECT p.post_title, d.price
FROM wp_posts p
JOIN wp_wpmcf_fg_product d ON d.mid = p.ID AND d.mtype = 'posts'
WHERE d.price < 100
ORDER BY d.price;Datumswerte: DATE, DATETIME oder ein Textwert
Eine DATE-Spalte passt für einen Wert ohne Zeitanteil – ein Veröffentlichungsdatum, ein Geburtsdatum, ein Ablaufdatum. Eine DATETIME-Spalte passt, wenn die Uhrzeit eine Rolle spielt, etwa bei einem Terminslot. Beides als Text („2026-08-28“) zu speichern funktioniert für die Anzeige zwar technisch, verliert aber die Möglichkeit, ohne Umwandlung chronologisch zu sortieren, und die Möglichkeit, Datumsberechnungen (Vorher/Nachher-Vergleiche, Zeiträume) über einen Index auszuführen.
Die Felder Date, Date and time und Time speichern native DATE-, DATETIME- und TIME-Werte und prüfen Eingaben streng, sodass ein Wert wie 2026-02-30 abgelehnt statt gespeichert wird. Datumswerte sind Ortszeitwerte in der Zeitzone Ihrer Website, ohne Umrechnung beim Speichern oder Lesen. Die akzeptierten Formate finden Sie unter Datum und Uhrzeit.
Der eine Fall, in dem Text manchmal weiterhin die pragmatische Wahl ist, ist ein Wert, der wie ein Datum aussieht, aber nicht als solches validiert werden soll – etwa ein Freitextfeld „gegründet in“ auf einer Geschichtsseite, bei dem die Quelldaten selbst uneinheitlich sind. Dafür eignet sich ein Text-Feld. Ist der Wert ein echtes Datum, das beim Filtern oder Sortieren verwendet wird, nutzen Sie einen echten Datumstyp.
Text: Wählen Sie eine Länge, statt unbegrenzt zu belassen
WordPress Core verwendet für alles Textartige gewohnheitsmäßig LONGTEXT, weil es nie im Voraus eine Längenbegrenzung erraten muss. Wenn Sie das Feld selbst verantworten, kennen Sie die Grenze meist: Ein Produktname wird nicht vier Kilobyte lang sein. Ein Text-Feld ist standardmäßig ein VARCHAR(255), ein Email-Feld ein VARCHAR(254), und in den SQL-Spaltenoptionen können Sie eine kürzere Länge wie VARCHAR(100) festlegen. Eine begrenzte Länge hält die Zeilen kleiner und macht einen Index auf dieser Spalte günstiger.
Freie Inhalte – eine Beschreibung, ein Rich-Text-Body – sind der berechtigte Fall für einen größeren Texttyp. Die Felder Text area und WYSIWYG verwenden LONGTEXT, weil Sie die Länge vorher nicht kennen und nicht nach dem vollständigen Inhalt sortieren oder indizieren müssen.
Boolesche Werte: ein echter Wahr/Falsch-Typ statt „yes“/„no“-Strings
Ein Feld mit nur zwei Zuständen sollte ein echter boolescher Typ sein und kein String wie "yes" oder "1", der bei jedem Lesen per Gleichheit verglichen wird. Das Feld True / false wird als TINYINT(1) gespeichert, sodass Sie mit WHERE featured = 1 filtern können. Das klingt nach einer Kleinigkeit – bis Sie in alten Zeilen drei leicht unterschiedliche String-Darstellungen von „wahr“ finden, weil sich vor drei Jahren einmal ein Formular geändert hat.
Wenn Sie gar nichts entscheiden müssen
Meistens muss diese Entscheidung nicht von Hand getroffen werden. Mass Custom Fields wählt anhand des im Editor gewählten Feldtyps einen sinnvollen Spaltentyp – ein Number-Feld wird zu einer Dezimalspalte, ein Date-Feld zu einer Datumsspalte –, sodass die üblichen Fälle ganz ohne SQL-Kenntnisse auskommen. Die Übersicht der Feldtypen listet die Standardspalte jedes Typs auf.
Indizes folgen den Typen, nicht umgekehrt
Ein Index ist nur so nützlich wie der Typ darunter. Wird eine Textspalte indiziert, die Zahlen als Strings speichert, ist bei der Abfrage weiterhin eine Umwandlung nötig, bevor Vergleiche funktionieren – das nimmt einem Index einen Großteil seines Nutzens. Wählen Sie zuerst den Typ – Preise in DECIMAL, Datumswerte in DATE, boolesche Werte in einen echten booleschen Typ –, und ein Index darauf tut, was Sie erwarten.
In den Constraints des Felds können Sie Add index für einen normalen Index oder Unique für Werte aktivieren, die sich nicht wiederholen dürfen. Als JSON gespeicherte Felder wie Checkboxen, Beziehungen, Gruppen und Repeater lassen sich nicht einzeln indizieren. Indizieren Sie nur Felder, nach denen Sie tatsächlich filtern oder sortieren, denn jeder Index verlangsamt Schreibvorgänge leicht; der Editor warnt ab acht indizierten Feldern in einer Gruppe. Diese Einstellungen behandelt die Seite Allgemeine Feldoptionen.
Später umentscheiden
Ein heute gewählter Typ muss nicht endgültig sein. Wenn Sie ein Feld auf einen kompatiblen Typ ändern, wird die Spalte angepasst und die Werte bleiben erhalten. Kann die Änderung Daten verlieren, etwa von Text zu Number, werden die alten Werte vor der Umwandlung in eine Backup-Spalte kopiert. Feldgruppen sicher ändern erklärt jeden Fall.
Fazit
Es gibt keinen universell „besten“ Typ, sondern den Typ, der dazu passt, wie der Wert tatsächlich verwendet wird. Zahlen, die Sie vergleichen oder sortieren, gehören in numerische Typen, Datumswerte in Datumstypen und kurze, begrenzte Texte in begrenzte Spalten. Wer das auf Feldebene richtig macht, beschleunigt jede Abfrage dieser Daten und macht jeden Vergleich korrekt – und genau diese Entscheidung lässt wp_postmeta Sie nie treffen.
