Cita: ¡Tiene implicaciones en el rendimiento de la Base de Datos?
Muchas. Si estás comenzando a aprender, te conviene primero leer sobre el modelo Entidad-Relación y las Bases de Datos Relacionales.
Hacerlo sobre la marcha hará que tengas que inventar la rueda varias veces hasta que aprendas los conceptos básicos (sin los cuales es casi imposible avanzar más allá de un a-b-c).
En referencia a la pregunta en sí, para todo sistema informático la búsqueda numérica es siempre más simple y rápida que una búsqueda de caracteres, entre otras cosas porque el valor de las cadenas de texto está condicionada por las collations y los charset, cosa que no sucede con los números, cuya valoración siempre es binaria.
Pero el tema central es que una clave primaria de una tabla no tiene necesariamente que ser un número incremental. Puede costruirse (y es mucho mejor) siguiendo simplemente los principios del modelo entidad relación: Una clave es un atributo (dato) o conjunto de atributos que permita identificar a un registro dado en el universo de valores posibles que un registro pueda tomar.
Esto significa que si tomas los datos específicos que componen la identidad de lo que la tabla representa siempre vas a encontrar uno o más de ellos que siempre existan y jamás se repitan (por ejemplo, el username, el numero de documento, el pasaporte, el ID de comercio, el numero de legajo judicial, etc.). Si no lo hay, puedes incluso obligar al usuario a que no pueda ingresar uno que ya exista, con lo que te aseguras la condición.
En este orden, una tabla de usuarios no necesita un ID numérico: Basta con usar el username elegido por el usuario y declararlo UNIQUE. Con eso, el propio username pasa a ser clave primaria de la tabla. ¿Es de caracteres? En este contexto la pérdida de performance posible se compensa y mucho con el hecho de que siempre necesitarás recuperar ese username para toda otra búsqueda. ¿Para qué crearle entonces una PK numérica?
En referencia a las notas de los usuarios en las otras tablas, esas ni siquiera necesitan de un ID numérico. En ese caso te conviene usar el username de quien emite la nota, y combinarlo con la fecha y hora de emisión de la nota. De ese modo puedes crear una PK combinada con dos campos, que tiene sobre las numéricas una ventaja: Como siempre vas a buscar las notas de los usuarios por su orden de ingreso, como ese mismo está dado por la clave primaria no necesitas hacer más combinaciones: El JOIN siempre te traerá los datos que requieres para ordenar o para buscar.
Todo esto, que parece complicado, en realidad parte de los fundamentos de las bases de datos relacionales, y es la forma eficiente y correcta de plantearlo.
Los modelos que puedes encontrar de bases usan más los ID numéricos por tres causas fundamentales: 1) Son fáciles de implementar. 2) No requieren razonar (o sea usar el cerebro), 3) Son comprensibles por los programadores, porque la mayoría no entiende bien el concepto de modelo E-R (que me perdonen si se ofenden, pero es la verdad), porque sólo lo dominas cuando te metes a fondo en análisis de sistemas o sistemas de bases de datos.
Pero así como son de fáciles tienen algunos problemas como: 1) Son problemáticos porque crean bases difíciles de migrar; 2) Traen muchos problemas en la consolidación de datos; 3) Tarde o temprano requieren un rediseño de las tablas cuando el uso de las bases se extiende en el tiempo; 4) Son más propensos a generar problemas por errores de implementación de las relaciones.
Espero no haberte mareado.
) 
