Depende de tu motor. La sabiduría común es que las lecturas son baratas, unos pocos bytes aquí y allá no afectarán significativamente el rendimiento de una base de datos de tamaño pequeño a mediano.
Más importante aún, depende de los usos a los que va a poner la clave primaria. Los números de serie enteros tienen la ventaja de ser fáciles de usar e implementar. También, dependiendo de la implementación específica del método de serialización, tienen la ventaja de ser rápidamente derivables, ya que la mayoría de las bases de datos simplemente almacenan el número de serie en una ubicación fija, en lugar de derivarlo Select max(ID)+1 from foosobre la marcha.
La pregunta es: ¿cómo presenta una clave de 5 caracteres un "valor significativo" para usted y para la aplicación? ¿Cómo se crea este valor? ¿Lleva más o menos tiempo encontrar un número de serie incremental? Si bien hay una cantidad trivial de espacio ahorrado en algunos enteros, la gran mayoría de los sistemas ignorará este ahorro de espacio.
No hay implicaciones de rendimiento, salvo que el esquema de caracteres requiere que nunca haya un motor automático, ya que sus "claves" son subestimables. Para su dominio específico, no se moleste con las claves artificiales, y solo use chino, japonés y tailandés como nombres clave. Si bien no puede garantizar la unicidad sobre cualquier aplicación posible, en su ámbito es mucho más razonable usarlas en lugar de abreviaturas horribles y forzadas de 5 caracteres. No hay impactos significativos en el rendimiento hasta que llegue a millones de tuplas.
Alternativamente, si solo realiza un seguimiento por país de origen, y no por cocinas regionales específicas (cantonesa, sichuan, siciliana, umbría, calabresa, yucateca, oaxaqueña, etc.), siempre puede usar los códigos ISO 3166 .
Si tengo 10,000 recetas, ¿no comienza a sumar la diferencia entre una clave de 5 caracteres y una de 20 caracteres?
El espacio es barato . Cuando habla de 10,000,000 de recetas en las que está haciendo operaciones OLAP, entonces, tal vez. Con 10k recetas, estás viendo 150k de espacio.
Pero de nuevo, depende. Si tiene muchos millones de registros, y está haciendo uniones en ellos, entonces tiene sentido desnormalizar la búsqueda de algo tan trivial (en una vista materializada). A todos los efectos prácticos, la eficiencia de unión relativa en una máquina moderna entre una clave de 5 caracteres y una clave de longitud variable es muy similar a ser idéntica. Afortunadamente, vivimos en un mundo de CPU abundante y disco abundante. Los desagradables son demasiadas combinaciones e ineficacia de consulta, en lugar de una comparación carácter por carácter. Dicho esto, siempre prueba .
Las cosas de P&T de este nivel dependen tanto de la base de datos que las generalizaciones son extremadamente difíciles. Cree dos modelos de muestra de la base de datos, complételos con el número estimado de registros y luego vea cuál es más rápido. En mi experiencia, la longitud de los caracteres no hace una gran diferencia en comparación con buenos índices, buenas configuraciones de memoria y otros elementos críticos de ajuste de rendimiento.