jer666 Posté(e) le 8 mai 2007 Partager Posté(e) le 8 mai 2007 bonjour, je desire creer une sorte de moteur de recherche en moins elaboré. en clair, des partenaires proposent leur flux rss, je les enregistre petit a petit et d'aprés les recherches renvois le lien vers les articles correspondantes aux mots clés. je debute un peu en programmation, 'jai fait quelques site en php, et je maitrise mal le xml. mais j'ais tout mon temps, je suis patient, et travailleur. mais la question de base ets de savoir si j'enregistre les articles dans ma base de données qui risque d'exploser rapidement, ou dans des fichier xml en enregistrant que le titre, la date et le resumé, par date et par categorie. le point positif du xml c'est le poids de la bdd qui sera reduite, le defaut c'est qu'il faudra parser tout les fichiers et donc c'ets lourds et long :( votre avis? merci ps: si vous avez des tuto sur la maniere de creer un moteur de recherche basé sur des flux rss je prends Lien vers le commentaire Partager sur d’autres sites More sharing options...
Cubic-Design Posté(e) le 8 mai 2007 Partager Posté(e) le 8 mai 2007 La solution de la base de données reste la plus "puissante" en terme de conception et possibilités Lien vers le commentaire Partager sur d’autres sites More sharing options...
tsubasaleguedin Posté(e) le 8 mai 2007 Partager Posté(e) le 8 mai 2007 Je vois pas en quoi le xml reste plus petit en terme de taille qu'une bdd, dans le principe tu as pas les index, ok tu gagne de la place en perdant des perfomance. Mais tu a surtout le l'information redondante avec les tag xml qui ce repete a chaque entrée. Donc je suis vraiment pas sur que tu sois gagnant en poids avec xml. Lien vers le commentaire Partager sur d’autres sites More sharing options...
savory Posté(e) le 10 mai 2007 Partager Posté(e) le 10 mai 2007 Pour un moteur de recherche derriere il faut assurement une base de donnée... Lien vers le commentaire Partager sur d’autres sites More sharing options...
lorinc Posté(e) le 10 mai 2007 Partager Posté(e) le 10 mai 2007 sauf que... l'avantage énorme du xml sur la solution mysql, c'est que le xml en tant que langage structuré te permet de rajouter des structure hétérogène sans avoir à tout modifier. Par exemple, si par la suite, tu veut ajouter un attribut à tes documents (le nombre de lecture), ça ce fera super simplement en ajouteant les trois lignes de code qui vont bien dans le parseur, alors qu'avec la bdd il faudra revoir la conception des table et se faire chier à recréer un colone ou une table, la remplir ex-nihilo, etc, etc. Pire : si tu veux stocker des données multiples (genre des keywords), avec le xml, c'est simple, tu rajoute un attribut <keyxord value="" /> et tu peux en coller autant que tu veux dans le fichier, c'est au parseur de se demerder pour les ajouter à une liste lors du parsing. Dans le cas bdd associative, soit tu bidouille en mettant un champ keywords qui contient une chaine où les keywords sont séparés par un caractère prévu (';' ou mieux '¤') auquel cas l'intérêt de la bdd associative est limité s'il faut quand même se taper un parsing, soit il faut que tu créé une table de key words, et que tu fasse les asociations inverses, bref, c'est une usine à gaz (et je parle même pas de lorsque que tu veux rajouter un keyword...) franchement, le choix n'est pas trivial. Si tu sens que tu est en une appli qui n'a pas de champs dont le nombre de valeur est variable et si tu sens que la structure de tes données va très peu varier, alors prends la bdd, tu te feras moins chier. Par contre, si tu penses que tu vas avoir des structures complexes et qui vont beaucoup varier dau moins dans un premier temps, prends le xml... my 2 cents Lien vers le commentaire Partager sur d’autres sites More sharing options...
theocrite Posté(e) le 10 mai 2007 Partager Posté(e) le 10 mai 2007 Je ne pense pas que ce soit vraiment plus compliqué en bdd. Pour rajouter une table en mysql, il suffit de faire : CREATE TABLE `matable` ( ** options, options ** ) type = truc; Et pour la supprimer : DROP TABLE `matable`; S'il faut juste ajouter un champs en fin de table, c'est : ALTER TABLE `matable` ADD ** options, options **; Pas besoin de 50 lignes. Les drivers existent dans tous les langages (bon il y a des parseurs xml aussi) et au moins on ne se retrouve pas avec une table incohérente. Lien vers le commentaire Partager sur d’autres sites More sharing options...
beuhbeuh Posté(e) le 11 mai 2007 Partager Posté(e) le 11 mai 2007 En fait ( et j'aimerais que jer666 confirme si je me trompe ou pas...) la question n'est pas utilisation de bdd ou de xml, mais que mettre dans sa base... Si j'ai bien compris son idée, aujourd'hui il pense à 2 solutions : 1) Mettre dans sa bdd : Données relatives au site + contenu des articles 2) Mettre dans sa bdd : Données relatives au site / Stocker le contenu des articles en xml Ce qui revient à la question d'utiliser ou pas les blobs pour stocker de gros documents textes... On entre ici dans un grand débat, plus ou moins philosophique, et les réponses vont beaucoup varier en fonction des personnes... Je vais donc donner ce qui n'est que mon avis : la 2ème solution est la meilleur, parce que la base sera moins grosse (donc probablement plus rapide, en fonction du serveur et du sgbd utilisé) et ses fichiers textes seront stockés comme ils doivent l'être, c'est à dire en tant que fichiers sur le disque et non en base... Lien vers le commentaire Partager sur d’autres sites More sharing options...
jer666 Posté(e) le 11 mai 2007 Auteur Partager Posté(e) le 11 mai 2007 c'est exactement ca beuhbeuh de toute facon la bdd est incontournable :) a savoir si elle enregistre tout tout tout, ou si elle n'enregistre que le minimum et le reste dans les fichiers xml. de plus ma question porte sur la rapidité d'accés aux données, merci lorinc et théo pour avoir penser au coté pratique. En "debutant" que je suis , il ne m'est pas toujours evident de voir mon "application" dans le futur. merci encore de toutes vos réponses! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.