Diseño de base de datos SQL recomendado para etiquetas o etiquetado [cerrado]

He oído hablar de algunas formas de implementar el etiquetado; usando una tabla de mapeo entre TagID y ItemID (tiene sentido para mí, pero ¿escala?), agregando un número fijo de posibles columnas de TagID a ItemID (parece una mala idea), manteniendo las etiquetas en una columna de texto que está separada por comas (sonidos loco pero podría funcionar). Incluso he oído que alguien recomienda una matriz dispersa, pero ¿cómo crecen con gracia los nombres de las etiquetas?

¿Me estoy perdiendo una práctica recomendada para las etiquetas?

Tres tablas (una para almacenar todos los elementos, una para todas las etiquetas y otra para la relación entre las dos), correctamente indexadas, con claves externas establecidas en una base de datos adecuada, deberían funcionar bien y escalar correctamente.

Table: Item
Columns: ItemID, Title, Content

Table: Tag
Columns: TagID, Title

Table: ItemTag
Columns: ItemID, TagID

Normalmente estaría de acuerdo con Yaakov Ellis, pero en este caso especial hay otra solución viable:

Use dos tablas:

Table: Item
Columns: ItemID, Title, Content
Indexes: ItemID

Table: Tag
Columns: ItemID, Title
Indexes: ItemId, Title

Esto tiene algunas ventajas importantes:

Primero, hace que el desarrollo sea mucho más simple: en la solución de tres tablas para insertar y actualizar item, debe buscar elTag tabla para ver si ya hay entradas. Entonces tienes que unirlos con otros nuevos. Esta no es una tarea trivial.

Luego hace que las consultas sean más simples (y quizás más rápidas). Hay tres consultas principales en la base de datos que hará: generar todas Tagspara una Item, dibujar una nube de etiquetas y seleccionar todos los elementos para un título de etiqueta.

Todas las etiquetas para un artículo:

3-mesa:

SELECT Tag.Title 
  FROM Tag 
  JOIN ItemTag ON Tag.TagID = ItemTag.TagID
 WHERE ItemTag.ItemID = :id

2-mesa:

SELECT Tag.Title
FROM Tag
WHERE Tag.ItemID = :id

Nube de etiquetas:

3-mesa:

SELECT Tag.Title, count(*)
  FROM Tag
  JOIN ItemTag ON Tag.TagID = ItemTag.TagID
 GROUP BY Tag.Title

2-mesa:

SELECT Tag.Title, count(*)
  FROM Tag
 GROUP BY Tag.Title

Artículos para una etiqueta:

3-mesa:

SELECT Item.*
  FROM Item
  JOIN ItemTag ON Item.ItemID = ItemTag.ItemID
  JOIN Tag ON ItemTag.TagID = Tag.TagID
 WHERE Tag.Title = :title

2-mesa:

SELECT Item.*
  FROM Item
  JOIN Tag ON Item.ItemID = Tag.ItemID
 WHERE Tag.Title = :title

Pero también hay algunos inconvenientes: podría tomar más espacio en la base de datos (lo que podría conducir a más operaciones de disco, lo que es más lento) y no está normalizado, lo que podría generar inconsistencias.

El argumento del tamaño no es tan fuerte porque la naturaleza misma de las etiquetas es que normalmente son bastante pequeñas, por lo que el aumento de tamaño no es grande. Se podría argumentar que la consulta del título de la etiqueta es mucho más rápida en una tabla pequeña que contiene cada etiqueta solo una vez y esto ciertamente es cierto. Pero teniendo en cuenta los ahorros por no tener que unirse y el hecho de que puede construir un buen índice sobre ellos podría compensarlo fácilmente. Por supuesto, esto depende en gran medida del tamaño de la base de datos que está utilizando.

El argumento de inconsistencia también es un poco discutible. Las etiquetas son campos de texto libre y no se espera ninguna operación como 'cambiar el nombre de todas las etiquetas "foo" a "bar"'.

Entonces tldr: Yo elegiría la solución de dos tablas. (De hecho, voy a hacerlo. Encontré este artículo para ver si hay argumentos válidos en su contra).

Si está utilizando una base de datos que admite la reducción de mapas, como couchdb, almacenar etiquetas en un campo de texto sin formato o en un campo de lista es, de hecho, la mejor manera. Ejemplo:

tagcloud: {
  map: function(doc){ 
    for(tag in doc.tags){ 
      emit(doc.tags[tag],1) 
    }
  }
  reduce: function(keys,values){
    return values.length
  }
}

Ejecutar esto con group = true agrupará los resultados por nombre de etiqueta e incluso devolverá un recuento del número de veces que se encontró esa etiqueta. Es muy similar a contar las ocurrencias de una palabra en el texto .

Use una sola columna de texto formateado [1] para almacenar las etiquetas y use un motor de búsqueda de texto completo capaz de indexar esto. De lo contrario, se encontrará con problemas de escala al intentar implementar consultas booleanas.

Si necesita detalles sobre las etiquetas que tiene, puede realizar un seguimiento en una tabla mantenida de forma incremental o ejecutar un trabajo por lotes para extraer la información.

[1] Algunos RDBMS incluso proporcionan un tipo de matriz nativa que podría ser aún más adecuada para el almacenamiento al no necesitar un paso de análisis, pero puede causar problemas con la búsqueda de texto completo.

Siempre mantuve las etiquetas en una tabla separada y luego tuve una tabla de mapeo. Por supuesto, nunca he hecho nada a gran escala tampoco.

Tener una tabla de "etiquetas" y una tabla de mapas hace que sea bastante trivial generar nubes de etiquetas y demás, ya que puede armar fácilmente SQL para obtener una lista de etiquetas con recuentos de la frecuencia con la que se usa cada etiqueta.

Sugeriría el siguiente diseño: Tabla de elementos: Itemid, taglist1, taglist2
esto será rápido y facilitará guardar y recuperar los datos a nivel de elemento.

Paralelamente, cree otra tabla: las etiquetas de etiqueta no hacen que la etiqueta sea un identificador único y si se queda sin espacio en la segunda columna que contiene, digamos 100 elementos, cree otra fila.

Ahora, mientras busca elementos para una etiqueta, será súper rápido.