Discussion pour le choix d'un nouvel identifiant pour les articles.

Actuellement, FreshRSS utilise un CRC32 pour identifier les articles, encodé en base64 modifié.

Cela représente des problèmes majeurs, en particulier un problème de collisions trop important, et le fait que c'est peu pratique et lent pour les requêtes SQL.

• Risque de collision : pour un hachage parfaitement distribué sur n-bit, le risque de collision dépasse 50% quand le nombre d'articles dépasse 2^(n/2), soit actuellement seulement 65535 articles pour FreshRSS (j'en ai déjà 32266 en ayant commencé en août).
  http://www.codinghorror.com/blog/2007/08/url-shortening-hashes-in-practice.html
  https://fr.wikipedia.org/wiki/Paradoxe_des_anniversaires
• Peu pratique pour les requêtes SQL : l’identifiant actuel n'est pas dans l'ordre chronologique et ne peut du coup pas être utilisé tel quel pour la pagination (oblige à faire un concat de la date et de l'ID, peu performant). Voir les commentaires de Exemples de flux avec des dates dans le futur #151 pour plus de détails.
• Actuellement, l'identifiant est stocké en texte, ce qui est moins performant qu'un entier en particulier pour une clef primaire, et surtout qu'un concat avec la date est nécessaire pour les requêtes principales. Voir http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html
• La date est actuellement un champ de requête très important, et n'est pas indexé. Ça serait mieux de remplacer ce rôle dans une majorité (en volume) de requêtes par une clef primaire efficace.

J'aurais voulu utiliser un champ date incluant les microsecondes, mais c'est disponible seulement depuis la version 5.6 de MySQL (par exemple pas disponible sur l'actuelle Ubuntu LTS), du coup abandonné
http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html

Du coup, je fais une proposition basée sur BIGINT (entier 64 bits) disponible sur MySQL depuis longtemps et SQLite :
http://dev.mysql.com/doc/refman/4.1/en/integer-types.html
http://www.sqlite.org/datatype3.html#affname