Barrapunto

El atributo nombre es mejor dividirlo en tres, nombre, apellido1, apellido2 o dejarlo en uno sólo

Si vas a usar los nombres y los apellidos por separado (ordenar por nombre, ordenador por apellido, ...) es mejor dividirlo, sino pues con guardar Apellido1 Apellido2, Nombre en un solo camba va que chutas.

Llega con usar el DNI (¿con o sin letra?) como primary key o es mejor usar algún campo id incremental. Esta entidad tendrá unas 500 entradas.

Te basta con el dni, nunca puede haber 2 personas con el mismo dni (en principio), por lo cual se puede usar perfectamente como primary key.

Yo pondría un campo para nombre, otra para el primer apellido y otro más para el segundo.
El DNI no lo usaría como clave primaria ni loco, por dos razones:

• Hay números de DNI repetidos
• Es muy fácil equivocarse al introducirlos

Eso sí, es muy útil tenerlos como un campo auxiliar (sobre todo el NIF y con cálculo automático de la letra).

Lo del nombre y apellidos. Ponlo en tres campos. Un consejo: Cuando diseñes una BD no pienses solo en que necesitas ahora, sino que puedes necesitar después, dentro de unos límites claro. ¿Es posible que en algún momento quieras ordenar por apellidos? Si, pues entonces, separa en tres campos.

Personalmente, siempre me gusta poner un id autonumérico. Creo que es más elegante. La razón es que el id se podría decir que es un campo "interno" de la base de datos, con lo cual, mejor que lo gestione la propia base de datos. Si ves que vas a necesitar ordenar después por dni, pues te creas un índice y marchando

... hablaré de lo mismo que los anteriores, pero así mejoras la estadística sobre las respuestas .-D

Separa el nombre en tres campos. Siempre estarás a tiempo de juntarlos de nuevo en uno sólo (si es necesario, cosa que dudo).

No uses el DNI como clave primaria. Confirmo lo que dicen arriba, en España se repiten los números, sobre todo si son de gente mayor.

Los autonuméricos son muy malos amigos en algun SGBD, parece que te ayudan pero a la larga te darán más problemas:

No uses autonuméricos como clave principal si no estás 100% seguro de que:
- nunca vas a llegar al límite del campo (yo no pondría la mano en el fuego por esto)
- no te va a dar problemas de integridad referencial al hacer o recuperar backups.
- manejas el sistema con soltura (sabes cómo volver a comenzar desde 0, por ejemplo).

Para aportar algo, te propongo que uses como clave principal algún tipo de "timestamp", con la mayor resolución posible, y da lo mismo si es numérico o alfa.

No encuentro ventajas para usar campos numéricos con preferencia sobre los alfa: en Oracle, por poner un ejemplo, ahorrarás espacio casi siempre usando varchar en vez de number (aunque, eso sí, podrías ahorrarte las comillas en los select :D)

Ah! recuerdo que OpenIngres tenía unas System Keys que funcionaban muy, muy bien ... Si tu SGBD las proporciona, también sería una opción cómoda.