Actuellement, la base de données utilise des types qui ne sont pas optimaux pour les données qu'ils contiennent, ce qui ralentit significativement les requêtes et augmente inutilement la taille de la base de données.
Suggestions, par ordre de priorité :

• Les identifiants (issus de small_hash = 32-bit) pour category.id et feed.id devraient être stockés sous forme d'entiers INT plutôt que de chaînes de caractère varchar(6). Voir SQL : Nouvel identifiant d'article entier basé sur la date #202 pour entry.id
  • Je trouverais d'ailleurs plus raisonnable d'utiliser au maximum 16 bits (SMALLINT unsigned < 65535) pour les identifiants de catégories et de flux. Il faut noter que le feed.id est tout de même répété pour chaque article (comme clef étrangère). Voir SQL : Nouvel identifiant entier pour les catégories et les flux #262
• Les valeurs booléennes comme feed.error, feed.keep_history, entry.is_read, entry.is_favorite devraient utiliser BOOLEAN plutôt qu'un entier 32-bit INT. Note au passage, les parenthèses après int comme int(2) n'ont aucun effet autre que cosmétique pour déterminer la taille des colonnes lors de l'affichage des résultats en ligne de commande. Fait b8821e6
• Utiliser VARCHAR plutôt que TEXT sur certains champs généralement courts et sur lesquels portent des requêtes, et CHAR plutôt que VARCHAR pour les champs de taille fixe. Fait b8821e6
  • VARCHAR supporte jusqu'à 65535 caractères depuis MySQL 5.0.3+ (la plus ancienne Ubuntu LTS, soit la 10.04, utilise MySQL 5.1. README mis à jour 1961120
• Considérer réduire feed.priority (actuellement INT 32-bit) pour quelques chose de plus raisonnable comme TINYINT ou au maximum SMALLINT. Fait 94c5f41
• Pour une date comme entry.date ou feed.lastUpdate, considérer TIMESTAMP ou DATETIME (moins important et plus discutable).