Barrapunto

Bien visto lo de los apellidos. Sólo remarcar que tengas en cuenta que en muchos países no se utiliza un segundo apellido si al final decides usar tres campos.

Se te olvida mencionar una ventaja del id autonumérico: que es un número. ¡Qué cosas! Cuando hagas operaciones JOIN entre tablas para acceder a datos, o cuando realices búsquedas, siempre es mejor trabajar con números que con cadenas. En el caso del NIF diste motivos más que suficientes para usar un id autonumérico, pero yo prefiero usarlo como clave primaria en lugar de una cadena siempre, y luego marcar la tupla que podría haber sido clave primaria como "sin duplicados" y marcarla para que se puedan realizar búsquedas rápidas (lo siento, no me acuerdo de los nombres 'tésnicos' ahora).

Creo que depende bastante de los requerimientos. Casi nunca utilizo como primary key un campo autonumérico, sino como índice normal. Más que nada porque un campo autonumérico ya evita que haya duplicados (almenos en rdbms serias, Access descartado). Y, evidentmente, si tu BD te lo permite ya que hay algunos motores que requieren por narices un primary key.

Normalmente en las tablas que uso para el registro de usuarios termino usando un campo autonumérico (imprescindible) pero coloco un primary key en otro campo para evitar duplicados de usuario. Debes controlar de alguna forma que de usuarios con un login/nombre/loquesea y una determinada contraseña sólo pueda haber uno. Sino, por mucho campo autonumérico que tengas ya veremos qué pasa cuando quieras sacar un campo de la tabla con un select, con los datos que te ha introducido el usuario, y ver que obtienes una matriz bidimensional de datos en lugar de una unidimensional (errores que no sabrás de dónde vienen, etc. etc. ). Claro que esto depende del modo en el que captures los datos de la bd.

Ahí queda eso. Saludos!