Avant de commencer, je fais une petite précision sur le mot “taxinomie”.
La taxinomie désigne une méthode de classification des informations dans une architecture structurée de manière évolutive, autrement dit les catégories, les tags, etc. (Plus d’informations sur Wikipedia)
WordPress 2.3 introduit un nouveau schéma pour la taxinomie. Il remplace les tables “categories“, “post2cat” et “link2cat” par 3 nouvelles tables bien plus flexibles.

La première table est “terms“, elle ne comprend que les informations de base relatives à chaque terme.
term_id bigint(20) NOT NULL auto_increment,
name varchar(55) NOT NULL default '',
slug varchar(200) NOT NULL default '',
term_group bigint(10) NOT NULL default 0,
PRIMARY KEY (term_id),
UNIQUE KEY slug (slug)
- “name” est le nom du terme
- “slug” est le nom optimisé pour l’URL
- “term_group” permet de grouper plusieurs termes ensemble
- “term_id” est un ID unique.
Un terme n’est ni une catégorie, ni un tag, cela dépend du contexte donné dans la table “term_taxonomy“.
term_taxonomy_id bigint(20) NOT NULL auto_increment,
term_id bigint(20) NOT NULL default 0,
taxonomy varchar(32) NOT NULL default '',
description longtext NOT NULL,
parent bigint(20) NOT NULL default 0,
count bigint(20) NOT NULL default 0,
PRIMARY KEY (term_taxonomy_id),
UNIQUE KEY term_id_taxonomy (term_id,taxonomy)
La table “term_taxonomy” spécifie un terme dans une taxinomie. Il peut en faire une catégorie ou un tag (ou les 2).
- “term_id” est l’ID du terme dans la table de termes (expliqué ci-dessous)
- “taxonomy” désigne la taxinomie qu’on emploie. Les taxinomies par défaut sont “category”, “post_tag”, ou encore “link_category”.
- “term_taxonomy_id” est l’ID unique pour la paire terme/taxinomie.
Le reste des champs fournit des informations à propos du terme dans le contexte de taxinomie.
- “parent” permet une relation de hiérarchie entre plusieurs termes d’une taxinomie.
- “description” propose de spécifier une description pour un terme dans une taxinomie donnée.
- “count” permet de compter le nombre d’objets associé à une paire terme/taxinomie
Par exemple, pour la taxinomie “category”, le champ “count” permet de savoir le nombre d’articles que contient chaque catégorie.
La dernière table, “term_relationships“, met en relation les objets comme les liens ou les articles avec le champ “term_taxonomy_id” de la table “term_taxonomy“.
object_id bigint(20) NOT NULL default 0,
term_taxonomy_id bigint(20) NOT NULL default 0,
PRIMARY KEY (object_id,term_taxonomy_id),
KEY term_taxonomy_id (term_taxonomy_id)
- “object_id” est l’ID d’un article ou d’un lien
- “term_taxonomy_id” est l’ID de la table “term_taxonomy” désignant une paire terme/taxinomie
La flexibilité de ce schéma et de l’API plugins permet d’ajouter de taxinomies et des objets très facilement. C’était l’un des points important du projet “Summer of Code“. Parallèlement, ce schéma nous autorise à récupérer facilement tous les objets associés à un terme donnés, sans préciser la taxinomie, récupérer tous les termes de toutes les taxinomies pour un objet donné, et aussi de convertir toutes les catégories en tags avec une requête.
Vous en apprendrez un peu plus sur le schéma de la taxinomie en consultant l’API des développeurs.
L’API des catégories assure une rétro compatibilité avec les versions précédentes. Les plugins effectuant des modifications directement sur les tables categories, link2cat ou post2cat seront buggés et non fonctionnels.
Voilà pour le schéma de taxinomie de la version 2.3. Il va causer quelques problèmes avec certains plugins dans un premier temps, mais à long terme il autorisera l’ajout de taxinomies sans modification du schéma de la base de données et c’est une excellente chose !
Source: Boren.nu