J'ai un site comme SO, Wordpress, etc, où vous faites un post et vous pouvez avoir des balises (optionnelles) contre cela.Un schéma de base de données pour Tags (par exemple, chaque poste a des balises facultatives)
Qu'est-ce qu'un schéma de base de données commun pour gérer cela? Je suppose que c'est beaucoup de structure, avec trois tables.
Vous avez des idées?
Une table de trois à plusieurs devrait être bien.
Par exemple. Posts, PostsToTags(post_id,tag_id), Tags
La clé est l'indexation. Assurez-vous que vous table PostsToTags est indexé dans les deux sens (post_id,tag_id et tag_id,post_id) même si les performances de lecture est très critique, vous pouvez introduire une vue indexée (qui pourrait vous donner POST_NAME, tag_name)
Vous aurez bien sûr besoin d'index sur les messages et les mots clés ainsi que.
Je me demandais si j'étais sur la bonne voie et il semble être :) –
Je ne suis pas entièrement sûr si c'est ce que le SO utilise. Mais il y a une bonne discussion here.
"Je suppose que c'est une structure de beaucoup de < ->, avec trois tables, quelqu'un a des idées?"
Plus précisément, il n'y a pas d'alternatives sérieuses, n'est-ce pas? Deux tables relationnelles dans une relation plusieurs-à-plusieurs requièrent au moins une table d'association pour transporter toute la combinaison de clés étrangères.
Le SO fait-il cela? Qui sait. Leur modèle de données comprend des comptages de référence, et - pour tous les horodatages connus et date de création et un grand nombre d'autres indésirables sur l'étiquette.
Au minimum, il doit y avoir trois tables.
Ce qu'ils font sur SO est difficile à savoir.
Ce serait une bonne idée de se pencher sur la façon dont WordPress gère les étiquettes pour les messages et il vous donnera une idée.
wordpress faire un beaucoup à beaucoup avec trois tables je crois. –
L'autre possibilité est bien sûr qu'il n'y a que deux tables.
Étant donné qu'il y a au plus 5 balises, une table de questions avec cinq références de clés étrangères nullables à une table de balises est une possibilité.
Pas très normalisé, mais il pourrait être plus performant.
peu probable que ce sera plus performant. il introduit des requêtes terriblement complexes lorsque vous recherchez plusieurs tags. –
et si les balises étaient stockées dans un champ varchar délimité et que vous pouviez utiliser une requête "like '% tag%" "contre ce champ, probablement encore peu indexable – benPearce
@ sambo99 - true dans ce cas et bon point. Trouver des questions pour un tag particulier serait nul. – Damovisa
pourquoi est-ce important de savoir comment SO implémente cela. mieux ouvrir une nouvelle question qui n'est pas si spécifique (si vous vous demandez comment SO met en œuvre des choses envoyer un courriel Jeff) –
vrai, je vais corriger mon titre de la question pour le rendre non spécifique. c'était surtout comme exemple, plus que tout. –