Alquimia Proyectos Digitales

Empresa de consultoría y desarrollo web Drupal | Barcelona

Análisis y diseño AI: ¿Qué usar, taxonomy o Nodereference?

Es probable que este post llegue tarde, ahora que tenemos Drupal 7 en la calle desde hace ya varios meses, pero seguramente aún hay muchos desarrolladores, particulares y empresas de desarrollo que valoran desplegar una web en Drupal 6 antes que Drupal 7 (que es motivo de una discusión diferente a la que no vamos a entrar a valorar ahora. Tampoco pretendemos con este artículo animar a los desarrolladores a utilizar D6 por encima de D7. De hecho, en D7, esta discusión no tendría sentido alguno, dado que con el nuevo modelo de entidades, carece de él). Todos los pros y contras que expliquemos en este artículo afectan únicamente a la elección de alguno de estos módulos en Drupal 6, nunca en portales desplegados sobre Drupal 7.

Vamos a plantear el uso de dos módulos muy extendidos en Drupal: Taxonomy y Node reference, al que vamos a añadir una posibilidad más que desde Alquimia hemos tomado en más de una ocasión, y para la que hemos desarrollado un módulo de interfaz que nos hace la vida más fácil. Explicaremos las opciones propuestas y sus pros y contras a continuación.

Content Taxonomy

Implicaría el uso de content taxonomy, en lugar de taxonomy, para una mejor integración con Views y facilitar la vida de los themers.

Pros

  • Permite jerarquía en la categorización.

Contras

  • No permite la extensión de campos, por lo que no se pueden considerar entidades propias.
  • No permite hacer referencia a dos categorías simultáneamente en el mismo campo.
  • No permite realizar un filtrado previo de las opciones a mostrar en el campo de categorización.
  • Es necesario sanitizar los argumentos para su uso con Views, cuando se toman los términos de taxonomía directamente como argumentos
  • En portales muy grandes, las relaciones (hablamos de integración con Views, de nuevo) harán perjudicar el rendimiento del site, puesto que todos los términos se escriben en la misma tabla, que tendrá unas proporciones desmesuradas.
  • De nuevo refiriéndonos a la integración con Views, si la cantidad de relaciones es mayor a 1, será necesario cruzar esta tabla (para establecer las relaciones), tantas veces, como relaciones hayamos establecido (empobreciendo el rendimiento del site).

CCk Text + CCK_Config

Implicaría el uso de campos CCK Text, con opciones de selección a modo combobox, mejorando la experiencia de usuario para la inserción, ordenación y edición de elementos de categorización con nuestro módulo cck_config. Podéis echar un vistazo al módulo en cuestión en drupal.org, aunque a efectos prácticos solo afecta a la UI, no tiene impacto alguno en el modelo de datos y/o en el rendimiento del site de cara al procesamiento de los mismos.

Pros

  • Ofrece un mejor rendimiento que Taxonomy.
  • Las relaciones se almacenan en las mismas tablas que los propios contenidos. No es necesario establecer relaciones a la hora de integrar con Views, ni hacer cruces de tablas terroríficas.
  • La integración con Views de cara al manejo de argumentos es simple y rápido.
  • En portales grandes, las relaciones no afectarán al rendimiento.

Contras

  • No permite jerarquización (uso de distintos niveles de profundidad en la categorización).
  • No permite la extensión de campos, por lo que no se pueden considerar entidades propias.
  • No permite hacer referencia a dos categorías simultáneamente en el mismo campo.
  • No permite realizar un filtrado previo de las opciones a mostrar en el campo de categorización.

Node reference

Pros

  • Permite la extensión de campos, por lo que pueden considerarse entidades propiamente.
  • Mejor rendimiento que taxonomy, pero no tanto como cck text + cck_config.
  • Permite jerarquías, pero en este caso, el rendimiento de esta solución empeoraría con respecto a taxonomy (se considerará como punto a favor y en contra).
  • Permite realizar referencias a varios tipos de contenido en el mismo campo, por lo que podemos establecer relaciones de forma simultánea a varias categorías en un único campo.
  • Permite hacer filtrado de los valores a mostrar en el campo node reference a partir de una view (lo que restringirá los valores a mostrar en el campo de categorización correspondiente).
  • La integración con Views de cara al manejo de argumentos es simple y rápido.
  • En portales muy grandes, las relaciones no perjudicarán el rendimiento en la medida en que lo hace taxonomy, dado que cada conjunto de relaciones está segmentado en una tabla diferente. De esta forma se consiguen obtener dos puntos de mejora respecto de Taxonomy (por un lado el cruce de tablas con una relación genera menor consumo de cpu para el servidor, y por otro, el cruce de tablas para más de una relación no implica rechar el mismo cruce n veces, sino varias tablas más pequeñas que se cruzan para hacer la relación específica efectiva).

Contras

  • Permite jerarquías, pero en este caso, el rendimiento de esta solución empeoraría con respecto a taxonomy (se considerará como punto a favor y en contra).

Conclusiones

Nuestra conclusión es simple. Si necesitamos campos que tengan como requisito la categorización con jerarquización a varios niveles de profundidad (y que estas categorías no sean consideradas entidades en sí mismas, es decir, no tengan atributos o metadatos asociados), usaremos content taxonomy. Si necesitamos categorización sin que las categorías sean consideradas entidades en sí mismas, es decir, no tengan atributos o metadatos asociados, pero no hay jerarquización, usaremos cck_config. En los demás casos, la opción debería ser Nodereference.