Si bien el diseño de una base de datos implica muchas cosas (cumplir con las formas normales por ejemplo) existen algunos consejos al diseñar los campos en una tabla para mejorar el rendimiento o performance de la base de datos:
1.- Escoger el tamaño más pequeño posible en datos numéricos
Cuando queremos guardar la edad de una persona -expresada en número de años cumplidos- se tienen varias opciones al escoger el tipo de datos ¿qué tipo de datos numérico será mejor? Para ello hay que considerar el rango de valores que se requiere (0 a 150 en este caso, quizá) el tipo específico (números enteros o reales). Una vez determinado esto, entonces se puede escoger entre las opciones que nos ofrezca el motor de bases de datos.
En este caso (edad en años, pero solo datos enteros) se puede escoger entre tinyint, smallint, int y bigint (si fuera SQL Server, por ejemplo). Si el consejo es escoger el tamaño más pequeño posible, se tiene que escoger tinyint, ya que permite guardar datos entre 0 y 255, rango más que suficiente para guardar los años cumplidos de cualquier persona.
Además de lo anterior, y en la medida de lo posible, se deberá preferir el uso de campos enteros por sobre los de punto decimal, ya que los enteros se almacenan de una manera que los hace más fáciles de guardar y de administrar. En el caso un porcentaje, por ejemplo, y si no hay un impedimento válido, se deberá guardar como entero (0 a 100) que como decimal (0.0 a 1.0).
2.- Usar el menor número de campos posibles.
Al diseñar una tabla, y considerando los requerimientos del usuario, saldrá una lista de campos candidatos. Es necesario valorar si todos los campos será útiles (en el presente o en el futuro) o solo se pusieron ahí «por si acaso». Si no se utiliza un campo lo preferible es eliminarlo del diseño físico.
3.- Uso de VARCHAR en lugar de TEXT cuando sea posible.
En SQL Server, si el campo texto es de menos de 8K de caracteres, lo recomendable es utilizar un tipo de dato VARCHAR que uno TEXT porque los primeros se almacenan de una manera que es más fácil de consultarlos, grabarlos y en general de administrarlos. En caso de que se requiera más de 8K de caracteres, la opción única será un campo TEXT.
4.- Privilegiar el uso de CHAR y VARCHAR sobre NCHAR y NVARCHAR
Si bien los campos Unicode (Nchar y Nvarchar) hace más portables las bases de datos (porque pueden guardar prácticamente cualquier caracter de cualquier idioma o lengua), lo más común será que nuestros sistemas no los requieran; por ello se recomiendo el uso de char y varchar sobre Nchar y Nvarchar, ya que los primeros ocupan 8 bits para representar cualquier caracter de texto, a diferencia de los segundos que ocupan el doble (16 bits) para cualquier caracter.
5.- Usar VARCHAR o NVARCHAR solo si los textos lo justifican.
Para guardar una cadena, existen dos opciones: usar un tipo de datos de longitud fija (CHAR y NCHAR) o de longitud variable (NCHAR y NVARCHAR). Los primeros son más fáciles de administrar (consultar y actualizar) pero los segundos aprovechan mejor el espacio.
Por ello, si un campo va a variar poco en su longitud (una clave que siempre se forma de 2 letras y 3 números o un RFC que es de 12 o 13 caracteres, por ejemplo) se deberán escoger los campos de longitud fija.
Si por el contrario, es un cadena que puede variar considerablemente en su tamaño (una dirección postal, por ejemplo) lo mejor será -privilegiando la longitud variable- usar VARCHAR o NVARCHAR.
6.- Evitar nulos en cadenas de longitud fija
Ya que los campos CHAR y NCHAR siempre son de la misma longitud, es un desperdicio que esos campos permitan nulos, ya que un campo de esos tipos, aunque contengan un NULL, ocuparán uno con todos los caracteres ocupados.
De preferencia definir todos los campos como NOT NULL
El permitir los nulos en los campos los hace más complejos en su consulta, lo que puede hacer los querys más complejos o más lentos, por lo que -a menos que haya una justificación de peso- ningún campo deberá permitir nulos.