Qué tablas crear en una Base de Datos

Durante el diseño de software que realizamos, en algún punto llegamos a preguntarnos qué cosas almacenar o registrar de lo que programaremos. Esto inmediatamente nos lleva a la duda respecto a qué tablas crear en una Base de Datos.

No es que exista un estándar ni mucho menos, sin embargo, podemos empezar separando las funciones del programa para visualizar cuáles serían nuestras necesidades en la base.

Direccionemos nuestra necesidad

En esta oportunidad no quiero entrar a debates respecto a Bases de Datos Relacionales o no Relacionales, ni a preferencias de motores o gestores. Si has pensado en utilizar el motor de Microsoft seguramente también te has preguntado cuál SQL Server es mejor.

Es evidente que el contenido de nuestra Base de Datos estará estrechamente ligada en los requerimientos del software que vamos a desarrollar o en los objetivos que le hemos dado en nuestra arquitectura. De todos modos, podemos hablar de algunas «categorías» que debemos tomar en cuenta.

Categorizar qué tablas podríamos necesitar

Reiterando que no hay una regla para esto, pero uno de los muchos caminos que podemos tomar para esta decisión puede ir de la mano de la agrupación en categorías respecto a lo que necesitamos. Por ejemplo:

a) Tablas de Entidades

Que den a conocer detalles de algún concepto en general como proveedores, países, ciudades, clientes, inventarios, productos, unidades, tiendas, categorías, parámetros…

b) Tablas Operativas

Referente a la atención del requerimiento del sistema. Pueden ser todas aquellas referidas a la transaccionalidad: operaciones, transacciones, débitos, créditos, pagos, préstamos, órdenes, flujos…

c) Tablas de Seguridad

Donde está la información de accesos y pistas de auditoría. Se puede considerar tablas de usuarios con credenciales de acceso al sistema, roles de usuarios, altas y bajas de usuarios. Información de auditoría como últimos accesos, datos modificados, usuarios y acciones realizadas…

d) Data Warehouse

(Si se considera un escenario de BI con DW). Tablas de hechos, dimensiones, tabla de fechas (ejemplos hay muchos en la web; puedes ver uno de Dinesh Asanka en MSSQLTips), tal vez tablas de staging…

e) Tablas de Log

De todos los sabores; dependerá del nivel de trazabilidad que queremos darle al sistema. Podemos considerar logs de conexiones de usuarios, conexiones de servicios, generación de errores, deadlocks…

Adicionalmente a discutir sobre qué tablas crear

No te olvides que en el diseño de sistemas, es muy importante considerar que todo es parte de un proyecto mayor. Son diferentes las personas que pueden ser afectadas cuando entregamos un nuevo software y en toda fase de planeamiento se debe tomar en cuenta varios detalles que nos eviten generar retrasos o confusiones en medio del desarrollo. Esto sobre todo con otras personas fuera del equipo de developers. En la publicación Participantes en un Proyecto con Base de Datos puedes ver mayor información.

Respecto a las relaciones entre tablas, es importante revisar conceptos de normalización si mantenemos una base relacional.

En cuanto a la estructura de tablas, un consejo personal es siempre tener un índice Clustered. Al menos evitamos los inconvenientes de las tablas heap que se generan por esta ausencia.