Jump to content

Spidetra

Hubmaster
  • Content Count

    326
  • Joined

  • Last visited

Everything posted by Spidetra

  1. J'abandonne ! C toi qui voit ça veut dire quoi : "ça fait moins propre" Ce qui ralentit les SGBRD : ce sont les mauvaises conception et les mauvaises requêtes, l'absence ou la mauvaise utilisation des index, etc.
  2. Petite remarque : avec ton code tu doit faire N+1 requêtes pour pouvoir afficher N lignes de produits. Si tu fait un INNER JOIN entre tes deux tables tu vas faire une seule requête On ne met jamais de requête dans une boucle
  3. Christian Emery - Directeur de Coliposte
  4. Salut blman, Si tes boss sont inquiets et qu'il faut les rassurer tu peux aussi leur proposer des solutions alternatives : - cryptage du mail en PGP : ça risque d'être pire, si tes interlocuteurs en face ne savent pas décrypter le mail. - Protection du RIB dans un pdf protégé par mot de passe, transmission du mot de passe soit dans un mail séparé soit par tél. Je suis assez d'accord avec les autres membres. Je ne pense pas que cela pose un pb de transmettre les RIB en clair. C'est pas toi qu'il faut convaincre, ce sont tes boss, c'est pas toujours le plus simple
  5. Tu sais, je suis un peu psycho-rigide J'aime bien répéter, 1.000 fois le même message, quitte a passer pour un emme.....deur Avoir une bonne structure dés le départ, c'est important pour des pb de performances et de facilité de programmation derrière. Ensuite on tombe sur des pb qui sont bc plus dur à régler en SQL du style : http://www.webmaster-hub.com/index.php?showtopic=22620
  6. Cette structure n'est pas adaptée à une DB performante et évolutive. Il en met combien de champ CategorieN : 1, 2, 3, 10, plus ? Disons qu'il en met 5. Qu'est-ce qu'il fait le jour où un jeu à 6 catégories ?
  7. ça dépend de ton choix de structure initial pour ta base de donnée.
  8. Voici une solution avec une base ayant une structure du type : jeux, jeux_categorie, categorie SELECT IDCategorie, count(*) FROM Jeux INNER JOIN jeux_categorie ON jeux.IDJeux = jeux_categorie.IDJeux GROUP BY IDCategorie
  9. Spidetra

    INSERT

    je ne pense pas : INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO] tbl_name [(col_name,...)] VALUES ({expr | DEFAULT},...),(...),... [ ON DUPLICATE KEY UPDATE col_name=expr, ... ] la syntaxe ne prend qu'une seule table et non pas une liste de table. Pour l'exemple j'ai pris la syntaxe mySQL, mais je pense que c'est pareil pour les autres SGBDR.
  10. GoogleBot Keep Out Je suis assez surpris par la méthode décrite par Matt Cutts dans ce billet pour interdire à GoogleBot d'indéxer une page. Par contre, je trouve le billet intéressant car il nous explique comment utiliser les wilcards dans un robots.txt pour contrôler l'indexation de GoogleBot. J'étais persuadé que les wilcards n'étaient pas pris en compte dans un robots.txt User-agent: Googlebot Disallow: *googlebot=nocrawl$
  11. regarde en bas de cette page : http://www.journaldunet.com/rubrique/url/index_url.shtml chaque semaine de nv litiges. Renseignes-toi auprès de l'afnic pour voir quelle est la procédure.
  12. Je t'offre un café Rassures-toi, j'avais même pas vu qu'il lisait dans un fichier. C'est ta solution qui me l'a montré. Pas réveillé non plus. Comme quoi, 2 cerveaux valent mieux qu'un
  13. Une première réponse possible : SELECT * FROM table WHERE champ IN ( XX, XX, XX, XX, XX ) Inspire toi de la solution de captain torche et génère la liste de ta clause IN en php. Là ou je ne suis pas d'accord avec captain torche : Ne jamais mettre une requête dans une boucle. Tu vas faire n requêtes, là ou une seule est suffisante. Maintenant : qu'est-ce que tu entend par infini ? Des millions de lignes dans le fichier, des milliers ou des centaines ?
  14. Je pense que tu cherches une mauvaise solution a un pb simple. C'est vraiment très très très rare d'avoir besoin de réorganiser une table comme tu viens de le faire. Ton pb se règle trés facilement en SQL : SELECT * FROM Table WHERE ( listes de conditions quelconques ) ORDER BY Nom LIMIT $1, $2 C'est l'impl"mentation classique d'un pager en mySQL. Et ça marche très bien. La syntaxe de ta requête SQL était fausse, et tu aurait dû commencer par la poster. Toujours choisir la solution la plus simple a un pb
  15. Ne touche pas à la structure de ta DB. Laisse ta clé primaire en auto-incrément. Ne te préoccupe pas de la manière ton SGBD insère et tri les enregistrements. Fais lui confiance te laisse le faire. Ta solution est très simple en SQL. SELECT * from TABLE ORDER BY Nom Cette solution ne te convient pas ? En fait je ne comprend pas trop ce que tu veux faire. De plus, si tu change les ID, et que ta table est lié à d'autres tables, tu va mettre toute ta base en vrac.
  16. A titre perso, je ne choisirai pas cette solution ! Un SGBDR est un système Relationnel C'est à dire un système optimisé pour gérer les relation entre les tables. Cette optimisation passe, entre autre, par la création des bons index sur les bons champs. 1. Imagine que tu désire supprimmer la catégorie n° 1. Avec un système normalisé une simple requête va te permettre de supprimmer toutes les liaisons entre tes jeux et cette catégorie. DELETE * FROM jeu_categorie WHERE IDCategorie = 1 Tu peux aussi gérer des triggers onDeleteCascade ou onUpdateCascade qui vont te permettre de maintenir la cohérence de ta DB. La gestion des triggers démarre avec mySQL 5.0. 2 Pour les pb de performances : => Il faut créer des index => Utilise un système de cache sur ton site 3. Commence d'abord par normaliser ta base de donnée. Ensuite, et seulement ensuite, tu peux dénormaliser ta table pour des raisons de performance ou de simplification. Il ne faut pas rester prisonier des règles de normalisation. Je ne sais pas si tu es en entreprise ou pas, mais essaye de prendre des bonnes habitudes de modélisation de tes bases de données.
  17. Pas de pb de performance si tu crée les index qui vont bien dans tes tables ( clé primaire et clé étrangère ) !
  18. NorSeb, t'as donné la solution tu as une relation de type many-to-many entre tes 2 tables
  19. Les moteurs de recherches n'utilisent pas un SGBD pour stocker et indexer les informations. Ils utilisent une structure connu sous le nom de : Inverted Index. Ce post essaye de décrire ce que je comprend de la structure d'un inverted index. J'espère que les zones d'ombres pourront être complété par les experts du Hub 1. Les fichiers qui composent un inverted index Un inverted index est composé de segments. Dans notre exemple nous avons un seul segment _0. Un segment est composé de différents fichiers. En particulier certains fichiers ont des extensions du type : .fnm, .tis, .frq, .prx Nous verrons un peu plus bas à quoi correspondent ces fichiers. Un des fichiers important de ce répertoire est le fichier segment. Ce fichier liste tout les segments présents dans notre inverted index. Dans notre exemple nous n'avons qu'un seul segment : _0 Le moteur de recherche va se baser sur ce fichier pour savoir quels sont les noms des fichiers d'index qu'il devrat manipuler. Dans notre exemple, ce sont les fichiers _0.fnm, _O.tis, _O.frq, _0.prx qui vont nous intéresser. Le fichier deletable contient des informations sur les documents qui ont été marqués pour suppression. Les fichiers ayant des extensions .fN ( N étant un nombre entre 0 et 8 dans notre exemple ) contiennent des informations sur les champs présents dans les documents indéxés. Dans notre exemple nous verrons que les 9 champs présents sont : anchor, content, dccreator, dctitle, host, site, tag, title, url 2. Le fichier .fnm : liste les noms des champs Ce fichier contient la liste de tout les champs composant l'inverted index. Vous pouvez voir que j'ai configuré mon crawler pour prendre en compte les méta Dublin Core ( dc:title et dc:creator ) Pour chacun de ces champs des flags indiquent les propriétés du champs : I, T, S, V I : Indexed => Le champ est indéxé T : Tokenized => Le champ est tokenize ( Découpé en mot ) S : Strored => Le champ est stocké V : Vector => ??? 3. Le fichier .tis : Dictionnaire des termes Ce fichier contient tout les termes de l'index. Un terme est un tuple contenant : Nom du champ et valeur du champ. Un terme de notre exemple : dctitle: XMLParser parse XMLData using Namespace and XPath Ce fichier contient aussi un document frequency. Cette valeur correspond au nombre de document du segment qui contiennent ce terme. 4. Les fichiers .frq et .prx : fréquences et positions des termes Ces deux fichiers listent les fréquences et les positions des termes dans l'ensemble des documents composant le segment. La structure d'un inverted index est un compromis entre deux chemin : - maximum de performance - minimum de ressources utilisées.
  20. un lien sur phlat : http://research.microsoft.com/adapt/phlat/default.aspx Search and Retrieval chez Microsoft
  21. La puissance économique de Microsoft fait encore peur aux milieux financiers. Dans les années 90, il suffisait que Microsoft décide de s'intéresser à un secteur, de racheter un ou deux acteurs économique, pour paralyser l'effort de R&D du secteur en question. Récemment ( fin février 2006 ), Georges Reyes évoquait les besoins financiers de Google. Comme par hasard, deux ou trois jours, plus tard Microsoft annonce qu'il vont "dévorer Google". Dans un contexte de guerre économique, une telle annonce peut paralyser les milieux financiers pendant quelques mois. ... ou alors Microsoft a vraiment embauché une armée de jeunes chercheur et mis en place un nouvel algo qui va déchirer sa race
  22. +1 pour robinsonvendredi si mysql5 possible.
  23. Choisit le code 2 Règle de base : on ne met jamais une requête SQL dans une boucle while ! En terme de performance c'est épouvantable. Pour ramener 50 lignes, tu vas faire 50 requêtes au lieu d'une seule. Si ta base est bien optimisé, aves les bons index, le code 2 devrait être plus performant. Compare les 2 solutions sur ton système. Tant que la charge de ton serveur ne sera pas trop importante, tout se passera bien. Et puis un jour tu chercheras à comprendre pourquoi ton appli ce met à ramer. J'impose la règle de base comme règle stricte de codage à tout mes développeurs. Comme tout règle elle souffre de quelques exceptions que nous cherchons à garder... exceptionelles
×
×
  • Create New...