Cela dépend de votre moteur. Il est communément admis que les lectures sont bon marché, quelques octets ici et là n'auront pas d'impact significatif sur les performances d'une base de données de petite à moyenne taille.
Plus important encore, cela dépend des utilisations auxquelles vous utiliserez la clé primaire. Les séries entières ont l'avantage d'être simples à utiliser et à mettre en œuvre. Ils ont également, selon la mise en œuvre spécifique de la méthode de sérialisation, l'avantage d'être rapidement dérivables, car la plupart des bases de données stockent simplement le numéro de série dans un emplacement fixe, plutôt que de le dériver Select max(ID)+1 from fooà la volée.
La question devient: comment une clé à 5 caractères présente-t-elle une "valeur significative" pour vous et pour l'application? Comment cette valeur est-elle créée et prend-elle plus ou moins de temps que la recherche d'un numéro de série incrémentiel? Bien qu'il y ait une quantité insignifiante d'espace économisé dans certains entiers, la grande majorité des systèmes ignoreront ces économies d'espace.
Il n'y a aucune incidence sur les performances, sauf que le schéma de caractères exige qu'il n'y ait jamais de moteur automatique, car vos "clés" sont indivisibles. Pour votre domaine spécifique, ne vous embêtez pas avec des clés artificielles et utilisez simplement le chinois, le japonais et le thaï comme noms de clé. Bien que vous ne puissiez pas garantir l'unicité de toute application possible, dans votre portée, il est beaucoup plus raisonnable de les utiliser au lieu d'abréviations horribles et forcées à 5 caractères. Il n'y a aucun impact significatif sur les performances tant que vous n'avez pas atteint les millions de tuples.
Alternativement, si vous effectuez un suivi par pays d'origine et non par des cuisines régionales spécifiques (cantonais, sichuan, sicilien, ombrien, calabrais, yucatèque, oaxaca, etc.), vous pouvez toujours utiliser les codes ISO 3166 .
Si j'ai 10 000 recettes, la différence entre une clé à 5 caractères et à 20 caractères ne commence-t-elle pas à s'additionner?
L'espace est bon marché . Lorsque vous parlez de 10 000 000 de recettes sur lesquelles vous effectuez des opérations OLAP, alors, peut-être. Avec 10 000 recettes, vous recherchez 150 000 d'espace.
Mais encore une fois, cela dépend. Si vous avez plusieurs millions d'enregistrements et que vous y effectuez des jointures, il est logique de dénormaliser la recherche de quelque chose d'aussi trivial (dans une vue matérialisée). À toutes fins pratiques, l'efficacité relative de la jonction sur une machine moderne entre une clé à 5 caractères et une clé à longueur variable est si similaire qu'elle est identique. Heureusement, nous vivons dans un monde de CPU et de disque abondants. Les méchants sont trop de jointures et d'inefficacité de requête, plutôt que de comparaison caractère par caractère. Cela dit, testez toujours .
Les choses P&T de ce niveau dépendent tellement de la base de données que les généralisations sont extrêmement difficiles. Créez deux exemples de modèles de la base de données, remplissez-les avec le nombre estimé d'enregistrements, puis voyez lequel est le plus rapide. D'après mon expérience, la longueur des caractères ne fait pas une énorme différence par rapport à de bons index, de bonnes configurations de mémoire et d'autres éléments de réglage des performances critiques.