Categorización en la base de datos

Modelo propuesto

Hasta el momento sólo he hablado acerca del modelo antiguo... ¿pero cuál es la propuesta super hiper maravillosa entonces?

Modelo Propuesto: menos tablas, más fácil para la vista

Este esquema nos presenta al menos a primera vista, algo bastante más simple que tener 20 a 30 tablas para distintas cosas: todo se reúne en una sola tabla, que en realidad es una subparte de otra.

Las ventajas de este modelo

1. Mejor mantención. En vez de tener 20 ó 30 tablas con categorías, ahora sólo se mantiene una, lo cual cumple al 100% del propósito de una base de datos: juntar en un solo lugar de manera optimizada mucha información. Por lo tanto, es posible manejar esa información mediante un administrador de categorías, con la cual podrán agregar, quitar o editar categorías de una forma más fácil que editando directamente la base de datos realizando cambios. De todas formas, si por ejemplo, deseara convertir todas las descripciones de las categorías a mayúscula, basta una consulta para convertirlos todos, sin equivocarse o sin olvidarse de una tabla.
2. Mejores índices (Estandarizados). Aunque en gran parte esta parte ya es cosa de cada uno, personalmente prefiero ocupar tres índices:
   • La primera para "acceso_directo", que guarda la cadena de 3 dígitos alfanuméricos cuya combinación es única.
   • La segunda para la tabla categorias, que es la clave primaria de esa tabla. Esta clave primaria es la que se referenciará en las demás tablas, así que es como importante.
   • La tercera, para la tabla categorías. Es una clave única compuesta por "acceso_directo" y "descripción" que opcionalmente se puede dejar como índice. (Sí: un índice NO ES lo mismo que una clave única, la clave única sólo asegura que el o los registros a los cuales se les hace el control no se vaya a repetir, pero no es implícitamente indexada a diferencia de una clave primaria, ese trabajo nos queda a nosotros). De esa forma, nos aseguramos de que las descripciones no estén repetidas, pero sí se puedan repetir en el caso que estén en distinta categoría.
     En cuanto a este índice opcional, hay que verlo caso a caso porque motores más potentes como PostGreSQL, que cumple 100% con ACID, saca el índice desde la tabla a la cual es referenciada, por lo que esta clave sería redundante, innecesaria e incluso puede perjudicar el rendimiento de la base de datos en vez de acelerarla. De todas formas se puede dejar sólo como una clave única, sin indexarla.

Las desventajas de este modelo

1. Consultas más complicadas. Aquí podrían haber dos casos: la primera y la segunda ( :retard ). Fuera de bromas, la primera es que desee rescatar la descripción asociada a una id y la segunda es que desee rescatar todas las categorías de un cierto tipo. (Por ejemplo, para elegir alguna opción de entre varios). De esta manera, para cada ejemplo, las respectivas consultas:

   -- Primer caso: uniendo dos tablas
   SELECT a.login, b.descripcion
   FROM usuarios AS a LEFT JOIN categorias AS b ON a.id_grupo = b.id_cat
   
   -- Segundo caso: rescatando todas las categorías de un cierto tipo
   SELECT id_cat, descripcion FROM categorias
   WHERE acceso_directo = 'etc'

   Por último, un pequeño truco si deseara rescatar por ejemplo la descripción de la id del curso Y la descripción del grupo:

   SELECT a.login, b.descripcion, c.descripcion
   FROM usuarios AS a, categorias AS b, categorias AS c
   WHERE a.id_grupo = b.id_cat AND a.id_curso = c.id_cat

Conclusiones

El diseño de la base de datos es importante y uno siempre tiene que pensar a lo grande. No sirve de nada pensar siempre en datos limitados, con entradas limitadas y sin esperanza de que crezca: si el sistema es bueno, va a crecer en algún punto.
Es por esto que prefiero para cualquier sistema, estandarizar las entradas y posibles salidas que tenga el sistema, y una de ellas es acortando la pega a la larga para el programador y además asegurando una consistencia en los datos.

Puede que uno de estos días hable en mayor profundidad acerca de eso. Pero por el momento, es lo que hay.

Saludos !!

Sobre Camilo Sperberg

Es Ingeniero Informático especializado en seguridad y PHP. En su tiempo libre le gusta estudiar nuevas técnicas de programación y escribir. Además, es amigo de todo ser viviente y cree que la tecnocracia es la mejor forma de política.