Diseño de Tablas en nuestra base de datos

Independientemente del tipo de motor en el que trabajemos, a la hora de diseñar una tabla siempre tenemos que tener una columna id unica que sea nuestra clave principal y parecera una tontera lo que digo pero he visto en algunas universidades y terciarios que no enseñan mucho sobre el diseño de bases de datos y sino agarren cualquier tesis de algun alumno y veran que al alumno no se le enseña a diseñar tablas ni bases

por ejemplo: si tenemos una tabla alumno tenemos que crear una columna id unica llamada por ejemplo idalumno y que sea incremental y otra columna tendra el dni del alumno pero jamas manejar la columna dnialumno como la columna clave en la tabla de alumnos y menos que menos en otra tabla
por ejemplo si tenemos las tablas de inscripciones alumnos y en ella metemos como parte de una clave el dni del alumno
todo muy lindo si el dni se cargo bien pero si despues de 5 meses te dicen que el dni estaba mal cargado tenes que actualizar cada tabla con el dni correspondiente manualmente o hacerlo por actualizaciones en cascada si hiciste la relacion de las tablas y se seteo que se haga actualizacion en cascada

pero a mi manera de ver siempre es conveniente no mezclar la clave fisica principal de una tabla que identifica cada registro con una clave restrictiva y logica como podria ser por dni de alumno, ya que dos alumnos no tendrian que tener el mismo dni entonces ahi si podemos crear un indice por dni y que sea unico pero que la clave principal no sea un dato de la entidad

La propiedad Nombre de los Controles y nombre de variables en nuestra aplicacion

Siempre sera una buena tecnica, trabajemos en el lenguaje que trabajemos de usar una forma estandar de llamar a nuestros controles en los formularios y a nuestros objetos en el codigo fuente

He visto muchas veces que la mayoria de los programadores usa los nombres por defecto cuando un control se inserta en un formulario ya sea web o windows
por ejemplo tirar una caja de texto un label, un boton y dejar los nombres:
textbox1, button1, label1

Cuando tenemos que meter codigo en el formualrio tenemos que recordar que representaba el button1, el texbox1 y se pierde tiempo en ver en el diseñador que representa dicho control

para los texbox por ejemplo:
txtNombreCliente es mucho mas representativo que textbox1
lo mismopara los botones:
btnAceptar es mucho mas representativo y claro que button1

Lo mismo curre cuando creamos objetos en variables, simpre acostumbrarse a buscar una forma estandar de crear los nombres y nuestreo codigo sera en cualquier lugar de la aplicacion mas entendible para nosotros y futuros desarrolladores de nuestras aplicaciones

por ejemplo para crear una varible de tipo formulario en visual vasic net

'defino una variable llamada objFrmClientes del tipo frmBrowseClientes
dim objFrmClientes as new frmBrowseClientes

para definir otro objeto del tipo formulario por ejemplo para proveedores seria:
dim objFrmPorveedores as new frmBrowseProveedor

asi cada vez que definamos objetos de un mismo tipo tienen una forma estandar de llamarlos