Bueno, como ya sabemos, las tablas son colecciones de registros, en un principio podríamos tener
tablas vacías, es decir, sin datos aún grabados en ellas.
Pero lo que sí ya tienen nuestras tablas es la definición de cómo estarán conformados esos registros,
es decir, cuando creamos nuestras tablas.
El segundo paso es diseñar su registro o colecciones de campos.
Estos campos son datos individuales donde en su interior sólo puede haber un valor alojado en comparación
con una planilla Excel.
Podríamos asemejar a un campo, a una columna determinada.
En la siguiente imagen podemos ver una definición de los campos de una tabla.
En mi ciclo veremos en secciones siguientes sobre la importancia de prestar cuidado y detalle a la creación
de nuestros campos para que nuestros datos se encuentren optimizados o, como se dice en bases de datos,
normalizado.
Pero siguiendo con el ejemplo de nuestra tabla llamada clientes, podríamos listar los campos que vemos
en la imagen como indispensables si prestan atención.
Yo ya estoy aplicando algunas reglas de normalización que ya veremos más adelante y refiere a que debemos
en lo posible nombrar nuestros campos de manera organizada, legible y siguiendo alguna norma.
En este caso, y teniendo en cuenta que una base de datos poseerá seguramente numerosas tablas y miles
de campos, es conveniente que el mismo nombre del campo nos dé una idea de qué se trata.
Si en lugar de Clío bajo nombre lo llamaremos simplemente nombre, deberíamos ver a qué tabla se refiere
para darnos cuenta de qué es el nombre del cliente o, por ejemplo, de un proveedor.
De esta forma, el nombre podría darnos rápidamente noción de su origen.
Ejemplos Elige un bajo nombre guion bajo nombre art.
Guion bajo descripción, ventas y un bajo.
Fecha de emisión.
Seguramente usted con solo leer el nombre de estos campos se dará una idea de qué valor contienen y
a qué se refiere dicho campo.
Pruebe ahora.
Tiene alguna forma de saber de qué tratan estos campos?
El nombre que le demos a nuestros campos es fundamental para una correcta interpretación de nuestras
tablas, campos y valores almacenados.
Si se fijan, es mi costumbre, la cual fue puliéndose con décadas de aprendizaje, que el campo comience
con cuatro caracteres o quizás algunos más que denoten.
De qué tabla proviene dicho campo?
Por ejemplo, los prefijos CLI guion bajo dan cuenta de que provienen de clientes y bajo proveedores.
Arte, guion bajo artículos o productos, ventas bajo tabla maestra de ventas son algunos ejemplos posibles
de tablas de nuestra base de datos, pero que nos dan una idea acerca de qué tabla provienen.
El uso de guion bajo para separar el prefijo del nombre.
Ustedes no están obligados a usar estos formatos o normas, sólo tomen los como consejo de un viejo
programador.
El otro aspecto que debemos atender es el tipo de dato de cada campo.
No es lo mismo una descripción que debe ser de tipo achar o parchar.
Esto lo explicaremos en detalle en otra sección de base de datos de Maisí.
No se preocupen en un campo fecha que un campo numérico, cada uno debe tener configurado de manera
correcta y teniendo en cuenta para dicho campo el valor mínimo y máximo que vamos a alojar.
Tenemos que encontrar la forma de concentrarnos en el tipo de dato correcto.
Por ejemplo, si nuestro campo número de sucursal.
Si sabemos que va a ser un campo que va a representar un número de sucursal y sabemos que a lo sumo
la empresa tendrá un máximo de 100 sucursales, no usaremos para este campo un tipo de dato que ocupa
4 bits y cuyo valor máximo es 4.000 294 millones 967 mil 200 95 posibilidades.
Sería un derroche de espacio en un solo campo, cuando en la tabla podemos usar un campo de tipo Tiny
INDT, que es el campo entero más pequeño posible, que solamente ocupa un byte y cuyo valor máximo
es de 255.
Es indispensable saber que ante la posibilidad de que algún día nuestro campo se quede corto, es decir,
que un valor alojado exceda el máximo permitido para un tipo de.
Podremos, sin perjuicio de la información grabada hasta ese momento, ampliar o cambiar el tipo de
dato.
Por ejemplo, hemos usado para el campo número de sucursal el tipo Tiny, cuyo valor máximo es 255 por
una expansión global mundial.
Nuestra compañía adquiere 300 sucursales de golpe y nuestros campos se han quedado chicos.
Ahí mismo podemos ir a nuestra tabla, cambiar el campo por Molinet, que ocupa dos bases en lugar de
uno y tiene un valor máximo de 65000 535 y listo.
Nuestro campo o columna ahora soporta números más grandes.
No hizo falta hacer nada en el sistema ni modificar programas, salvo que internamente tuvieran validaciones
que limitaran el valor del campo.
Pero no hay que hacer ni siquiera backups adicionales a la base de datos y en solo un segundo y grabando
los cambios en la tabla, seguimos camino.
Por eso mi consejo es que siempre habrá posibilidad de ampliar y mejorar la tabla, pero en un comienzo
usen datos concretos, normales y coherentes.
A nadie se le ocurriría, por ejemplo, crear un campo CLI nombre e indicarle al motor que dicho campo
tendrá un largo de 300 caracteres.
Imaginen nuestra tabla con 1000 registros de clientes y por cada uno de ellos reservando el espacio
para 300 caracteres.
Serían unos 300000 bits para alojar solamente 1000 nombres.
No hay mejor sortearlo de 60 caracteres.
Cada campo puede ser inicializar con un valor por default, es decir, que si no se le mueve explícitamente
un valor, el campo sea inicializar o con un valor en concreto en los campos numéricos.
Ese valor de foll generalmente es cero o comilla comilla, o sea espacio vacío cuando es un tipo de
carácter, un tipo de campo tipo string o parchar o char.
Vamos a saber mucho más sobre los campos conforme vayamos avanzando en este curso y ahora los invito
a ver la siguiente clase, donde aprenderemos todo sobre los índices en las tablas.