2010-09-16 17 views
9

tengo 3 planes:¿Cómo diseñar el esquema para algo así como etiquetas de preguntas de StackOverflow?

1, en la tabla preguntas:

question 
------------------------------------ 
id title content ...  tags 
------------------------------------ 
1 aaa  bbb  ...  tag1,tag2,tag3 (use , to split more tags) 

2, en la tabla de etiquetas y dividir:

tags 
------------------------------------ 
id tag 
------------------------------------ 
1 tag1,tag2,tag3 (use , to split more tags) 

3, en la tabla de etiquetas:

tags 
------------------------------------ 
id tag 
------------------------------------ 
1 tag1 
2 tag2 
3 tag3 

Creo que el plan 3 es mejor, pero ¿cuál es su opinión?

¿Alguna otra buena idea para esta implementación?

Gracias por la ayuda :)

+2

favor ver [ Como recomiendan la implementación de etiquetas o etiquetado ] (http://stackoverflow.com/questions/20856/how-do-you-recommend-implementing-tags-or-tagging). –

Respuesta

12

Estos patrones se llaman mysqlicious, scuttle y toxi (del menos al más normalizado).

Todos ellos tienen sus ventajas y desventajas. Puede leer un buen análisis bastante aquí:

http://forge.mysql.com/wiki/TagSchema (WayBackMachine Version)

Tenga en cuenta que mysqlicious depende en gran medida de la capacidad de su base de datos para realizar búsquedas de manera eficiente FULLTEXT.

Esto significa que para MySQL con InnoDB y para algunos otros sistemas es muy poco práctico.

1

depende de la forma normalizada desea que sus datos sean.

En primer lugar, me estremezco cuando veo una columna "id" en una tabla que no es única. Al menos cambie el nombre de la columna a "question_id".

En segundo lugar, depende de si desea una lista rápida de todas las etiquetas definidas. En este caso, querría una tabla de etiquetas por separado que defina el conjunto de posibles etiquetas, y luego una tabla intermedia entre las preguntas y las etiquetas que proporcionan una asociación de muchos a muchos.

6

La relación entre las etiquetas y el contenido es many-to-many. Lo que esto significa es que una etiqueta se puede asociar con varias unidades de contenido, y una unidad de contenido se puede asociar con varias etiquetas.

Para implementar esto en una base de datos, puede usar una tabla auxiliar llamada ContentTags. La relación de Content a ContentTags es de uno a muchos; la relación de Tags a ContentTags es de uno a muchos.

#Tags Table 
Id Text 
1 'Tag1' 
2 'Tag2' 
3 'Tag3' 


#Content Table 
Id Content 
1 "some content" 
2 "other content" 
3 "more content" 

#ContenTags Table 
ContentId TagId 
1   1 
1   2 
2   1 
2   2 
2   3 
3   1 

Como se puede ver, la relación se refleja claramente (contenido 1 se asocia con las etiquetas 1 y 2; el contenido 2 está asociada con etiquetas 1, 2 y 3; contenido 3 sólo se asocia con la etiqueta 1)

1

El enfoque correcto es crear las relaciones uno-muchos, es decir, tiene un comentario y varias etiquetas.De WIKI

En la tecnología de bases de datos, se produce una relación uno a muchos (también conocido como muchos) cuando una entidad está relacionada con muchas ocurrencias en otra entidad. Por ejemplo, un club tiene muchos miembros.

Y el concepto principal en el diseño de la base de datos es el Database normalization.

Así lo haría así.

comments 
------------------------------------ 
id_comment title content 
------------------------------------ 
12   aaa  bbb 

tags 
------------------------------------ 
id_tag comment_id tag 
------------------------------------ 
1  12   tag1 
2  12   tag2 
3  12   tag3 
+0

Este tipo de diseño tendrá ** mucha redundancia ** en la ** etiqueta ** archivada porque muchos comentarios comparten las mismas etiquetas. Por ejemplo, podríamos tener 1 millón de comentarios etiquetados como "etiqueta1". Por cierto, si acepto la redundancia, entonces veo otro problema: no sirve de nada colocando ** id_tag ​​** y ** tag ** al mismo tiempo en la ** tabla de etiquetas **. Solo necesitamos etiqueta, ** no necesita ID_tag si esta tabla ya tiene comment_id **. –

Cuestiones relacionadas