Trouver les doublons

[heretik25]

Bonjour,

Je travail sous mysql et j'aimerais être capable de trouver les mots clés qui sont en doublons ou plus dans mon champs TEXT "mots_cles".

J'aimerais être en mesure d'avoir via une requête les mots clés et le nombre d’occurrence.

Ex :

mots_cles ||nbre_occurrence
test || 4
toto || 2


A savoir que les mots clés sont séparés par une virgule dans le champ.

Auriez-vous une idée ?

Par avance merci.

[stealth35]

Envoyé par heretik25

A savoir que les mots clés sont séparés par une virgule dans le champ.

le problème est là, tu dois faire du relationnel c'est fait pour ça les bases de données

[heretik25]

Envoyé par stealth35

le problème est là, tu dois faire du relationnel c'est fait pour ça les bases de données

Le champ que je souhaite exploité est utilisé pour la balise META keywords. Côté administration, un textarea accueil les différents mots clés que l'utilisateur souhaite mettre en avant.

Un mot clé n'est pas attaché à plusieurs contenus. J'aimerais connaître les redondances afin de créer avec les mots les plus utilisé, un nuage de tag.

Cordialement.

[Tolriq]

Tu ne pourras pas par mysql.

Il te reste a le faire coté php a coup de explode array_merge & co mais stocker des données avec des ; dans mysql c'est dommage car cela perds tout l’intérêt de la chose.

[heretik25]

Envoyé par Tolriq

Tu ne pourras pas par mysql.

Il te reste a le faire coté php a coup de explode array_merge & co mais stocker des données avec des ; dans mysql c'est dommage car cela perds tout l’intérêt de la chose.

Effectivement mais il n'est pas facile, lorsque tu es novice en développement et en base de données de tout bien faire dès le départ. Surtout que je ne savais pas où mon projet allait me mener car il dépend de mes activités sportives.

Aujourd'hui, j'ai envie de tout remettre à plat car j'ai une idée bien meilleure de ce que j'attends de mon site mais ce n'est pas chose facile. Lorsque je demande un coup de main pour remodéliser ma base, je me retrouve en face d'Ayatollah de la modélisation. (Ce n'est pas méchant ce que je dis, au contraire) et je me décourage.

L'étape une serait donc de modéliser correctement mes besoins,
puis de réinjecter toutes les données dans la nouvelle modélisation en créant les relations. Pour ce côté là, je maitrise un outil ETL du nom de FME donc je devrais m'en sortir.
la troisième partie serait le fait de modifier le code source du site pour l'adapter (nouvelles requêtes...).

Seul la première partie me semble insurmontable ! Si il y a des amateurs pour m'aider, je leur serait reconnaissant.

Comme tu le soulignes, il reste la solution php avec explode.

[ledisciple]

eh oui, le bon vieux papier crayon n'est toujours mis au rancart. Il faut commencer par concevoir un bon système relationnel de base des données. Il faut que tu vois de quelles infos tu as besoin (en te posant des questions sur tes besoins) De toute façon, moins tu mets d'information dans tes tables ( surtout des doublons) et plus tu auras de chance d'avoir une bonnes base de données. Essaye de créer une première table pour commencer ...

Il faut que tu nous fournisses cela d'abord.

[heretik25]

Cela fait un moment que je réfléchit sur les besoins de mon site et voici ce qu'il en ressort :


Un article est écrit par un utilisateur ayants les droits suffisants. Il contient les données communes des différents articles (titre, timestamp, description, mots clés, validation). Les mots clés devront pouvoir être utilisé pour la génération d'un nuage de tag avec redirection vers un article précis contenant le mot clé. Chaque article possède son propre répertoire photo qui peut être classé par type d'article selon l'année, le mois, le jour.

Un article peut être soit:

• une balade
• un périple
• un test de matériel
• une news
• un partenaire
• un lien amis
• la réponse à une question générale
• une question FAQ
• entretien du vélo
• une présentation

On peut imaginer que d'autres types d'articles s'ajoutent au fur et à mesure des évolutions. Chaque article sera validé par un administrateur sauf lorsque c'est lui même qui écrit l'article.

Précisions sur les besoins des différents articles :

• "Une balade" peut être soit à pied, à vélo... La balade est associée, à un département et parfois à un fichier GPX (trace GPS). La trace GPS contient une multitude de points contenants (latitude, longitude, élévation, datetime). Grâce à ces données, un script va chercher à géolocaliser les photos sur les points GPS les plus proche grâce à l'heure de la prise de la photo issue des données EXIF. Un module cartographique exploitera ces données pour créer la trace de la randonnée, des statistiques, un export KML et un profil d’élévation via la class Artichow.
  
  
• "Un périple" peut-être à pied, à vélo...et son contenu est découpé en plusieurs pages car très long. Un périple peut donc avec 1 ou n pages. Le périple est associé à un secteur géographique (France, Europe, Monde) et parfois à un fichier GPX (trace GPS). (même principe que pour la balade au niveau de la trace GPS et du module cartographique.)
  
  
• "Un test de matériel" est inféodé à une catégorie (vêtements, bivouac,orientation,vélo,randonnée...). La catégorie possède une position afin de pouvoir gérer l'ordre d'affichage.
  
  
• "Entretien" est un article inféodé à une catégorie (transmission,roues,...) et est liée à une durée (10 mn, 20mn,30mn et plus) et une difficulté (facile moyen, difficile). La catégorie possède une position afin de pouvoir gérer l'ordre d'affichage.
  
  
• "FAQ"est inféodé à une catégorie (le site, GPS,...). La catégorie possède une position afin de pouvoir gérer l'ordre d'affichage.
  
  
• "News", "partenaire», "liens amis", "question", "présentation" sont des articles "simples" et n'ont pas de gestion particulière.
  
  
• Un article peut être commenté par les utilisateurs. Un commentaire peut se faire à son tour commenter (système similaire au forum) mais sans possibilité de modifier le commentaire commenté. Un utilisateur ne peut pas commenter son propre commentaire s'il n'a pas été commenté. L'utilisateur pourra modifier, supprimer son commentaire sans que cela impacte le système.
  
  
• Un livre d'or permet aux utilisateurs de poster leur ressentis sur le site et ce sans modération.

Qu'en pensez-vous ?

[ledisciple]

le premimer jet en pièce jointe. j'ai pas mis les jointure, car j'ai pas le logiciel pour

[heretik25]

Envoyé par ledisciple

le premimer jet en pièce jointe. j'ai pas mis les jointure, car j'ai pas le logiciel pour

Voilà ce que j'arrive à faire de mon côté.

Qu'en penses-tu ?

[ledisciple]

la critique est facile ....

Dans article : article_url_photo : il va n'y a avoir qu'une seule photo par article?

Je ne vois pas la relation qu'il pourrait y avoir entre article et article_simple. Pourquoi vouloir absolument lier les deux tables?

Je ne comprends pas pourquoi tu créés une nouvelle table pour type_article_simple ? Pourquoi ne pas simplement ajouter un champ de liste sous article simple ?

Pourquoi créer deux tables pts_gpx ?

J’ai beaucoup de doutes (mais pas de réponses) pour intégrer des mots clef dans une base de données.

[heretik25]

Envoyé par ledisciple

la critique est facile ....

Dans article : article_url_photo : il va n'y a avoir qu'une seule photo par article?

Je ne vois pas la relation qu'il pourrait y avoir entre article et article_simple. Pourquoi vouloir absolument lier les deux tables?

Je ne comprends pas pourquoi tu créés une nouvelle table pour type_article_simple ? Pourquoi ne pas simplement ajouter un champ de liste sous article simple ?

Pourquoi créer deux tables pts_gpx ?

J’ai beaucoup de doutes (mais pas de réponses) pour intégrer des mots clef dans une base de données.

Je suis demandeur de critiques !

Pour les photos dans les articles, je pensais stocker l'adresse url du dossier contenant les photos de l'article

Entre article et article_simple. Effectivement, c'est à méditer mais étant donné qu'il y a des champs commun entre ces deux tables comme le titre, le timestamp... je me suis dit que l'on pourrait essayer de généraliser ?

Un article simple peut être une présentation, une news... type_article_simple c'est en quelque sorte une table de référence ou j'irai piocher quand je créerai l'article simple.

Deux tables gpx car ça évite d'avoir une clé étrangère non remplie. Comment gérerais-tu ce cas ?


Pour les mots clés, je suis aussi dans l'expectative.

Il y a aussi l'histoire des commentaires que je sais ne pas être bon car on ne peut pas commenter un commentaire.
Merci pour ton aide !

[ledisciple]

Envoyé par heretik25

Entre article et article_simple. Effectivement, c'est à méditer mais étant donné qu'il y a des champs commun entre ces deux tables comme le titre, le timestamp... je me suis dit que l'on pourrait essayer de généraliser ?

Généraliser? ce n'est pas parce que deux tables se ressemblent qu'il faut absolument les lier !!

Envoyé par heretik25

Un article simple peut être une présentation, une news... type_article_simple c'est en quelque sorte une table de référence ou j'irai piocher quand je créerai l'article simple.

Je pense que tu as raisons sur ce point. Créer une table à part (plutôt qu'un champ de liste, permet une mise à jour plus facile des champs

Envoyé par heretik25

Deux tables gpx car ça évite d'avoir une clé étrangère non remplie. Comment gérerais-tu ce cas ?

Je ne comprends pas ta réflexion

[heretik25]

Ok, je vais revoir pour l'article simple.

Pour le table pts_gpx.


Si j'associe la table pts_gpx aux périples et aux balades, je vais me retrouver avec une table pts_gpx avec deux clés étrangères :


id_pts_gpx
...
id_periple
id_balade

Étant donné qu'une trace GPS n'est pas associé à la fois à un périple et une balade, je vais me retrouver dans la table avec une des deux clés étrangères de remplie.


ex si c’était un fichier gps d'un périple:

id_pts_gpx id_periple id_balade
1 |1|null
2 |1|null

Après, ce n'est peut être pas dramatique ?

[grunk]

J'ai peut être pas saisie toutes les subtilités de ton besoin mais ton premier diagramme me semble bien compliqué.

un dénominateur commun les articles. Chaque article peut avoir un type particulier. Chaque article peut avoir un type de données qui lui est propre.

De là pourquoi ne pas simplement faire :

- Une table Article , avec les éléments commun à tous les articles (quelque soit leur type).
- Une table Article_Type , liée à article et qui contiendra les différent type d'article
- Une table Articles_Extras, liée à article qui va contenir les éventuelles données supplémentaires pour tes articles.
Cette table aura autant de champs que de données possible (GPS, difficulté,durée ...) et ne seront remplis que ceux qui sont nécessaire.
- Une table Catégories puisque chaque article peut également dépendre d'une catégorie.

Une autre façon de voir les choses (celle que je préfère en général) est de dissocier totalement tes type d'articles. Finalement une question de FAQ n'a pas grand chose à faire dans la même table que le récit d'un périple par exemple. Tu va certes augmenter le nombre de table , mais au final l'exploitation en sera sans doute simplifiée.

[heretik25]

Envoyé par grunk

J'ai peut être pas saisie toutes les subtilités de ton besoin mais ton premier diagramme me semble bien compliqué.

un dénominateur commun les articles. Chaque article peut avoir un type particulier. Chaque article peut avoir un type de données qui lui est propre.

De là pourquoi ne pas simplement faire :

- Une table Article , avec les éléments commun à tous les articles (quelque soit leur type).
- Une table Article_Type , liée à article et qui contiendra les différent type d'article
- Une table Articles_Extras, liée à article qui va contenir les éventuelles données supplémentaires pour tes articles.
Cette table aura autant de champs que de données possible (GPS, difficulté,durée ...) et ne seront remplis que ceux qui sont nécessaire.
- Une table Catégories puisque chaque article peut également dépendre d'une catégorie.

Une autre façon de voir les choses (celle que je préfère en général) est de dissocier totalement tes type d'articles. Finalement une question de FAQ n'a pas grand chose à faire dans la même table que le récit d'un périple par exemple. Tu va certes augmenter le nombre de table , mais au final l'exploitation en sera sans doute simplifiée.

Je vais essayer de regarder pour proposer une solution alternative en suivant tes conseils. Je revient vers vous dans quelques minutes.

[heretik25]

C'est clair que ça simplifie énormément mais est-ce une bonne façon de faire d'ajouter tous les extras dans une table extra ? Beaucoup de champs risques d'être vide.

[grunk]

D'un point de vue forme normale c'est sans doute loin d'être la meilleure solution. Mais ça facilite grandement la récupération des données.

Pour les mots clés , je procède comme suit quand j'ai besoin de faire des nuage de tag :

- une table Keywords , qui va contenir tous les mots clé de manière unique (donc contrainte d'unicité sur le libellé)
- Une table Keywords_Article , qui va faire le lien entre les articles et les mots clé.
pour un même article tu pourras donc avoir plusieurs lignes dans Keywords_Article.

De cette manière il est très simple de compter combien de fois est un utilisé un mot clé.

[heretik25]

Pour les mots clés, j'appliquerai la règle de gestion suivante :


1 article peut contenir 0 ou n mots clés
des mots clés peuvent être utilisés dans 1 ou n articles

ce qui donnerait le mcd en pj et le mpd en pj ?

[grunk]

ce qui donnerait le mcd en pj et le mpd en pj ?

Oui

[heretik25]

En ce qui concerne les commentaires. Comment gérer le fait qu'un utilisateur puisse commenter un commentaire (récursivité) mais pas le sien.

EDIT : Comment aussi gérer le fait qu'un périple a un contenu énorme qui doit être "découpé" par page ?

Ex : http://partir-en-vtt.com/php/periple...type_periple=1