sql - keywords - meta tags ejemplos

Formas de implementar etiquetas-pros y contras de cada uno (5)

Bueno, tengo la misma duda que adopté la tercera solución para mi sitio web. Sé que hay otra forma de resolver este problema de las tuplas de longitud variable que consiste en utilizar columnas como filas de esta manera, tendrá alguna información que identifique la tupla redudante y las variables organizadas una para cada fila.

+--------+-------+-------------------------------------+ | postId | label | value | +--------+-------+-------------------------------------+ | 1 | tag |C++ | +--------+-------+-------------------------------------+ | 1 | tag |search | +--------+-------+-------------------------------------+ | 1 | tag |code | +--------+-------+-------------------------------------+ | 1 | title | Why is a raven like a writing desk? | +--------+-------+-------------------------------------+

Esto es realmente malo, pero a veces es la única solución viable, y está muy lejos del enfoque relacional.

Usando SO como ejemplo, ¿cuál es la forma más sensata de administrar etiquetas si anticipa que cambiarán con frecuencia?

Modo 1: seriamente desnormalizado (delimitado por comas)

Aquí las etiquetas están delimitadas por comas.

Pros : Las etiquetas se recuperan a la vez con una única consulta de select . Actualizar etiquetas es simple. Fácil y barato de actualizar.

Contras : análisis adicional en la recuperación de etiquetas, es difícil contar cuántas publicaciones usan qué etiquetas.

(alternativamente, si se limita a algo así como 5 etiquetas)

table posts +--------+-------+-------+-------+-------+-------+ | postId | tag_1 | tag_2 | tag_3 | tag_4 | tag_5 | +--------+-------+-------+-------+-------+-------+ | 1 | c++ |search | code | | |

Modo 2: "Ligeramente normalizado" (tabla separada, sin intersección)

table posts +--------+-------------------+ | postId | title | +--------+-------------------+ | 1 | How do u tag? | table taggings +--------+---------+ | postId | tagName | +--------+---------+ | 1 | C++ | | 1 | search |

Pros : Es fácil ver los recuentos de etiquetas ( count(*) from taggings where tagName=''C++'' ).

Contras : tagName probablemente se repetirá muchas, muchas veces.

Modo 3: El niño fresco (normalizado con la tabla de intersección)

table posts +--------+---------------------------------------+ | postId | title | +--------+---------------------------------------+ | 1 | Why is a raven like a writing desk? | table tags +--------+---------+ | tagId | tagName | +--------+---------+ | 1 | C++ | | 2 | search | | 3 | foofle | table taggings +--------+---------+ | postId | tagId | +--------+---------+ | 1 | 1 | | 1 | 2 | | 1 | 3 |

Pros :

No se repiten nombres de etiquetas.
A más chicas les gustarás.

Contras : Es más caro cambiar las etiquetas que la manera # 1.

Creo que SO usa la solución # 1. Yo iría con el # 1 o el # 3.

Una cosa a considerar es si tiene varias cosas que puede etiquetar (por ejemplo, agregar etiquetas a publicaciones y productos, por ejemplo). Esto puede afectar la solución de base de datos.

Estas soluciones se denominan mysqlicious , mysqlicious y toxi .

Este artículo compara los beneficios y desventajas de cada uno.

Yo diría que hay una cuarta solución que es una variación de su tercera solución:

Create Table Posts ( id ... , title ... ) Create Table Tags ( name varchar(30) not null primary key , ... ) Create Table PostTags ( PostId ... , TagName varchar(30) not null , Constraint FK_PostTags_Posts Foreign Key ( PostId ) References Posts( Id ) , Constraint FK_PostTags_Tags Foreign Key ( TagName ) References Tags( Name ) On Update Cascade On Delete Cascade )

Observe que estoy usando el nombre de la etiqueta como la clave principal de la tabla Etiquetas. De esta manera, puede filtrar en ciertas etiquetas sin la unión adicional a la propia tabla de etiquetas. Además, si cambia el nombre de una etiqueta, actualizará los nombres en la tabla PostTags. Si cambiar un nombre de etiqueta es algo raro, entonces esto no debería ser un problema. Si cambiar el nombre de una etiqueta es algo común, entonces me gustaría ir con su tercera solución en la que usa una clave sustituta para hacer referencia a la etiqueta.

Yo personalmente prefiero la solución # 3.

No estoy de acuerdo con que la solución # 1 sea más fácil de mantener. Piense en la situación en la que tiene que cambiar el nombre de una etiqueta.

Solución # 1:

UPDATE posts SET tag = REPLACE(tag, "oldname", "newname") WHERE tag LIKE("%oldname%")

Solución # 3:

UPDATE tags SET tag = "newname" WHERE tag = "oldname"

El primero es mucho más pesado.

También tiene que lidiar con las comas al eliminar etiquetas (OK, se hace fácilmente pero aún así, es más difícil que solo eliminar una línea en la tabla de taggings )

En cuanto a la solución # 2 ... no es pez ni ave