Sondage moteur de recherche

[Fredo_L]

Actuellement, il y a 3600 magazines sur le site. Ce serait super une immense base de données pouvant ressembler à un truc dans ce genre là :

* Nom du magazine
* Numéro du magazine
* Date du magazine
* Nom d'un jeu
* Type d'info du jeu : Test, solution, preview, article, actualité, etc.
* Si c'est un test, avec l'auteur
* Si c'est un test, avoir la note
* si c'est une solution, savoir si c'est une solution complète, un cheat, etc.
* Avoir les références des pages parlant du jeu
* machine qui se rapporte à l'article (amiga, pc, mac, atari, cpc, etc.)
* etc.

A mon avis, si on prend un magazine comme Joystick qui faisait 350 pages et qui parlait d'un nombre considérable de jeux, faire une telle base de données prendrait 2 heures. Pour faire l'ensemble des magazines du site, cela prendrait donc plusieurs mois à plein temps.

Est-ce que quelqu'un serait motivé pour réaliser cette base de données ?

[Kantaro]

J'avais commencé à réaliser une "base de données" sous forme de tableur (car les bases de données proprement dites, du style access ou open office base, je n'y connais rien).

Pour apporter ma pierre à l'édifice, je la mets en fichier joint.

Je projette normalement de reprendre cette "base de données", de manière lente mais soutenue, pendant mes vacances.

[Fredo_L]

J'ai Excel 2003 et je n'arrive pas à lire ta base de données.

L'objectif serait de faire une base de données universelle pour l'ensemble des magazines du site. Il faudrait donc se mettre d'accord sur une structure commune.
A mon avis, il faudrait donc recommencer tout depuis le début.

Par exemple, pour les dates, il faudrait prendre la structure yyyy-mm-dd
Avoir une colonne HS pour signaler quand il s'agit d'un numéro HS.
Pour les numéros des Joystick, ne pas écrire 5, 15, 150 mais 005, 015 et 150.

Si tu te sens motiver pour faire ce travail sur tout le site, je peux réaliser un modèle très précis de la base de données, avec toutes les explications et tu n'auras plus qu'à remplir la base de données.

[Poil]

Ce serai un gros plus

[canelle]

Ce serai un gros plus

Si on te fournit la structure de la base ainsi que les instructions précises, te sentirais-tu prêt à aider ?
A deux, ça ira plus vite et ce sera plus motivant.

Edit : j'ai pu lire la base avec Office 2007 mais en effectuant une réparation.

[Kantaro]

Le fichier joint que j'ai envoyé ci-dessus était réalisé avec Open Office, ce qui pourrait expliquer les problèmes de compatibilité/corruption.

Je viens de reporter les données sur un tableau réalisé avec Excel 2003, afin d'éviter ce genre de problèmes (voir nouvelle pièce jointe). Fredo, celui-ci est-il lisible ?

Sinon, pour ce qui est de la base avec un modèle à remplir, pas de problème, ça serait un gros plus en effet.

Il est clair qu'à deux ou plusieurs, ça irait plus vite, et ça permettrait de se répartir les magazines.

Juste une petite remarque sur la structure, que tu propose, Fredo, yyyy-mm-dd, le "dd" ça implique de connaitre le jour de sortie du magazine, ce qui, à ma connaissance, n'est pas le cas pour une grande majorité des mensuels et bimestriels disponibles sur le site.
Je peux me tromper, bien sur...

[canelle]

J'ai pu lire ton fichier sans problème cette fois sauf que, je n'ai plus que 14 entrées...

Pour le format de la date, je pense que Fredo voulait dire qu'il voulait dire que pour un mag sorti en mai 1995, il voudrait une date 1995-05.

[Kantaro]

Les 576 entrées de tests sont dans un des autres onglets du classeur :-p

(le glissement d'un onglet vers un autre se fait en bas à gauche de la fenêtre normalement)

[canelle]

Exact !
J'avais regardé trop vite.

[Soily]

Je pense que je pourrais participer à un projet de ce genre, ça me plairait. Par contre il faut que la structure de la base de données soit parfaitement bien pensée avant de commencer, c'est le plus important pour éviter les problèmes par la suite. Aussi, il faut s'assurer que la saisie soit faite "parfaitement" (sans fautes, etc)

Au niveau de la saisie, comment tu envisagerais ça Fredo? Une interface web spécifique sur ton site pour les "saisisseurs"?

[Soteen]

Je ne pense pas avoir de temps alors je ne vais pas proposer mon aide pour l'instant !

[Fredo_L]

Je répondrai demain si j'en ai le temps.
Ce soir, je suis assez pris.

[Fred_G]

Je sais pas si ça peut aider, mais apparemment, certaines personnes ont deja fait des indexs de magazines. Je suis tombé là dessus par hasard:
http://www.youngmonkey.ca/nose/magazine ... ewsFR.html

[Poil]

Il faudrait formuler comment sont composés les magazines :

Exemple (oui c'est un exemple en 2minutes de reflexion) :

• 1 magazine a un nom, un numéro, une date de parution
• 1 magazine est composé de N articles
• 1 article a 1 classification (Jeu, Logiciel, Programmation ...)
• 1 article a 1 type d'article (Test, Preview, Astuce, Actu, Tutorial ...)
• 1 article a 1 titre.
• 1 article a n mot clé (dont 1 principal pour retrouver les jeux facilement) ?

Je vous laisse compléter, corriger donner vos idées ... en fonction de cela le schéma de BDD sera facile à faire

[Fredo_L]

Je m'en rends compte que j'ai mis trop longtemps ce sujet de côté par manque de temps.
Je le mets dans mon dossier "à faire" et a priori, je m'en occuperai sérieusement dans le courant de la semaine prochaine.

Je vous laisse compléter, corriger donner vos idées ... en fonction de cela le schéma de BDD sera facile à faire

A priori, tu es demandeur d'une base de données données ambitieuse car elle te permettrait de plus facilement trouver un article.
A 3 reprises, il t'a été demandé si tu étais prêt à contribuer à cette base de données (c'est à dire, consacrer beaucoup de temps à compléter la liste) mais tu ne réponds jamais. En gros, le travail consistera à télécharger un magazine et à inscrire tous ses articles dans la base de données.
Merci de répondre clairement pour dire si oui ou non, tu souhaites participer à la création de la base de données.

[Fredo_L]

Comme promis, je viens donner des informations.

Tout d'abord, je vais essayer de répondre à la question de Soily concernant la saisie.
Il y a plusieurs solutions :
1) On met en place un fichier Excel et il faut travailler directement dessus. A mon avis, c'est la solution la plus simple s'il n'y a qu'une ou deux personnes pour réaliser la base de données.
2) On met en place un fichier Excel, qui va être mis en partage sur Google Docs. L'avantage est que cela permet de travailler facilement à plusieurs dessus.
3) Je mets en place une intervalle pour saisir directement dans la base de données du site. Comme ce sera un travail en ligne, prévoir une attente de quelques secondes à chaque ajout.

Mon objectif est de faciliter le travail de ceux qui travailleront sur cette base de données.
J'invite ceux qui ont l'intention de travailler sur cette base de données, à indiquer leur préférence et ce sera cette solution qui sera retenue.

[Soily]

Alors pour ma part, par déformation professionnelle, je n'aime pas trop l'idée du fichier Excel Je suis plutôt partisan d'un vraie base de données bien construite d'entrée de jeu.

Donc à priori je préfère plutôt la solution 3, mais bon ça demande du boulot pour créer une interface à peu près ergonomique pour saisir rapidement. L'avantage c'est qu'on pourra travailler en parallèle, et qu'on aura directement une BDD exploitable sur le site (mais ça aussi, ça demandera du boulot à mettre en place).

Une autre possibilité, mais je pense que ça ne sera pas jouable à cause de la structure de la BDD (voir ci-dessous), ce serait un petit logiciel qu'on ferait tourner localement pour saisir les données, et qui génèrerait des scripts SQL d'insertion. Je pourrais faire une petite appli de ce genre en Java. Mais le problème de cette solution, c'est qu'en fonction de la structure des tables, on ne peut pas l'utiliser (notamment au niveau des clés primaires/clés étrangères, à causes des numéros de séquence générés automatiquement, et auxquels on n'aurait pas accès avec une appli locale, contrairement à des pages web tournant directement sur le serveur)

En tout cas, avant de décider, il faudrait réfléchir à la structure de la base de données (analyse) comme a commencé à le faire Poil un peu plus haut, afin de bien définir les données que l'on veut stocker, et comment on va les organiser (tables, colonnes, clés étrangères et clés primaires)

En s'inspirant des idées de Poil et de quelques autres idées en plus, ça donne une structure de ce genre (à corriger et enrichir) :
Remarque : En gras les clés primaires, en souligné les clés étrangères faisant référence à une autre table.
MAGAZINE(ID Magazine, Nom Magazine, Editeur, Type magazine, date première parution, date dernière parution)
Les ID sont générés automatiquement via une séquence (système d'auto-increment en MySQL)
On peut éventuellement ajouter une ou plusieurs colonnes pour les noms alternatifs et les changements de noms. Le genre de magazine correspond à celui qu'on trouve sur le site des magazines (peut aussi être extrait dans une table de nomenclature), les autres champs sont facultatifs.

NUMERO (ID Numéro, ID Magazine, numéro, hors-série, date parution, période, nombre de pages)
hors-série est un booléen indiquant si c'est un numéro HS, pour la date de parution je pense qu'il faudra définir une convention commune car on ne pourra pas connaître la date réelle (exemple : on décide que si c'est un numéro janvier/février 1990, on indique une date de parution au 1er janvier 90 - ceci afin de pouvoir faire des recherches par date), et la période sera par exemple "janvier février 1990"

TYPE ARTICLE (ID Type Article, libellé type article)
Dans cette table, on répertorie tous les types d'articles connus : Couverture (pour un jeu faisant la couv du magazine), test, preview, astuce, plan, solution, dossier, cheat, listing, publicité etc etc.
Extraire ces données dans une table permet d'éviter la redondance d'infos dans la base.

ARTICLE (ID Article, ID Numéro, ID Type Article, Numéro de page, auteur, longueur)
On trouve ici des références au numéro de magazine dans lequel figure l'article, ainsi qu'au type de l'article. L'auteur pourrait être extrait dans une table supplémentaire, car on retrouvera souvent les mêmes journalistes. Quant à la longueur, c'est un nombre de pages, voir comment gérer les petits articles (plusieurs astuces sur une même page par exemple), éventuellement mettre 1 page comme taille minimale même si l'article est plus court, pour simplifier.

MACHINE (ID Machine, Nom machine)
JEU (Id Jeu, Nom Jeu, (genre jeu?))
=> On peut envisager d'enregistrer d'autres infos sur les machines et les jeux ultérieurement

LANGAGE(ID Langage, nom langage)
Pour les magazines micro qui proposent des listings (genre des programmes en BASIC)

SUJET(ID Sujet, ID Article, ID Machine, ID Jeu, ID Langage)
Table qui fait le lien entre un article et son ou ses sujets (un article peut porter sur le même jeu sur différentes machines, ou bien un dossier peut concerner plusieurs jeux d'une ou plusieurs machines)

Voilà, c'est juste une ébauche, j'ai sûrement oublié des choses ou bien je me suis trompé quelque part (je suis pas mal rouillé en analyse à vrai dire, ça fait un bail que je n'en ai pas fait sérieusement :p)

Ca a peut-être l'air un peu compliqué comme ça (plein de tables et tout) mais en fait les seules tables qui vont beaucoup évoluer sont les articles, les jeux et le lien du sujet des articles. Les numéros aussi, dans une moindre mesure. Le reste évoluera très peu une fois que les données qui vont bien auront été mises en place.

[Kantaro]

Alors la solution que propose Soily (la 3) peut me convenir, tout comme la 2.

Par contre, pour ce qui est de la création de la structure de la BDD, vu que je maitrise très mal cette chose là, je vais laisser Fredo ou Soily la mettre au point.

Pour remplir la BDD une fois qu'elle est mise au point, vous pouvez bien entendu compter sur moi (ça se présentera comment, au niveau visuel ? une interface graphique, genre un formulaire à remplir, ou autrement ?)

[Fredo_L]

On va partir sur l'idée 3.
Ce sera effectivement un formulaire à remplir.
L'avantage de la méthode 3, c'est que tout ce qui sera rempli, sera immédiatement opérationnel par le moteur de recherche.

Dans un premier temps, ce sera un formulaire à remplir en ligne. Par la suite, il sera possible de réfléchir à un logiciel qui sera peut être plus agréable pour travailler sur la base de données.

Je vous tiens rapidement au courant pour la suite, et notamment la structure de la base.

[Fredo_L]

Je vais essayer de mettre en place le système de saisi en place sur le site pendant cet été.
Si le système de saisi au travers du site est trop chiant, alors, je chercherai une autre solution (par exemple, développer une application).

Je vous donne la structure de la base de données :

1) id ==> nombre entier qui servira à avoir une référence unique et de clé primaire
Ce champ sera automatique rempli.

2) ref_mag ==> nombre entier donnant la référence d'un magazine disponible sur le site.
Cela donnera automatique les informations suivantes :
- Nom du magazine
- Numéro du magazine
- Date de sortie du magazine
- Image de la couverture

3) type_article ==> cela peut être un test, solution, avant-première, programmation, listing, couverture, article généraliste, une actualité, reportage, dossier, pub, interview, etc.
Il n'y aura rien à taper. Il s'agira d'un menu avec sélection.

4) sujet_article ==> dans le cas d'un test, d'une avant-première, ou d'une solution d'un jeu, on donnera le titre du jeu. Dans le cas d'une interview, on donnera le nom de la personne interviewer. Dans le cas d'un reportage sur un studio de développement, on donnera le nom du studio de développement.

5) auteur_article ==> si c'est signalé dans le magazine, donner le nom de la personne qui a rédigé l'article. Supposons que je sois fan de Marcus, je pourrais comme ça faire une recherche sur Marcus et retrouver tous les tests de jeux qu'il a rédigé.

6) note_test ==> Si l'article est un test et qu'il y a une note, alors, on peut donner cette note (par exemple : 95%, 3 sur 5, 4 étoiles, mega star, super hit, etc.

7) type_solution ==> si dans type d'article, on a mis solution, on peut préciser de quel type de solution, il s'agit. Est-ce une solution complète, une astuce ou des conseils, un plan, un tips, un cheat, etc.
Il n'y aura rien à taper. Il s'agira d'un menu avec sélection.

8) page_article ==> On indique la ou les pages qui contiennent l'article. Si l'article est sur la page 120, on marquera 120.

9) machine_jeu ==> si l'article parle d'un jeu, préciser sur quel support a été testé le jeu (amiga, pc CD-ROM, mac, atari, cpc, megadrive, NES, gameboy, etc.).
Il n'y aura rien à taper. Il s'agira d'un menu avec sélection.

10) contributeur ==> donne le nom de celui qui a fait
Ce champ sera automatique rempli.

J'ai fait quelques essais et avec ces informations, le moteur de recherche fonctionne assez bien.
Je propose que l'on reparle de tout ça dans un mois car cela sera à ce moment plus concret. On pourra voir à ce moment, ce qui peut être amélioré ou changé.