Spidetra

Quand on parle de base de donnée, généralement on fait allusion aux SGBDR. R voulant dire : relationnel. Donc pour toutes les appli faisant appel à des modèles Relationnels, il est normal que Google et les autres fassent appel à des SGBDR. Concernant, le moteur de recherche lui-même : 1. Les données ne sont plus relationnelles 2. N'importe quel SGBDR serait à la ramasse Le stockage des données pour les outils de recherches se fait dans des structures que l'on nomme : Inverted Index.

C'est ce point qui me surprend ! Je n'utilise jamais d'index FULLTEXT, mais à priori, j'aurai envie de dire que ce genre de recherche est assez souple pour résoudre tes problèmes. Tu aurais un exemple de recherche que tu arrive à faire avec un LIKE, et pas avec une recherche FULLTEXT ? Si tu poste la structure de ta table, un petit jeu de donnée et les recherches qui posent un pb avec LIKE, on pourra s'amuser à essayer de t'aider. Les requêtes en FullText me semblent quand même assez souple ( petit extrait du manuel ) :

En fait, comme dit un plus haut, je ne comprend pas vraiment le pb de Mamat. Je dois être un peu trop psycho-rigide FULLTEXT => Match AGAINST. Concernant les LIKE, l'optimisation relève du parcours du combattant. Je ne suis même pas surs qu'il soit possible d'optimiser des requêtes LIKE. En fait, je dois avouer que j'utilise très peu souvent LIKE, si possible jamais. La réponse au pb de Mamat a été donné par le premier post de Vincent. Ce qui en veut pas dire que le reste de la discussion soit inutile. Bien au contraire Je vois que l'on partage la même conception des choses Le nbr de prise de becs que j'ai pu avoir avec des developpeurs pour leur imposer le modèle intervallaire ! Je me sentirais moins seul Mais là on est en train de dériver du post initial

Je me rend compte que j'ai été trop catégorique dans mon précédent post. En fait il faut remplacer ON par JE. Je ne cherchais pas à imposer des pratiques, juste à décrire les miennes. C'est la mise en production qui impose les pratiques d'optimisation. Je m'impose un certains nbrs de règles d'otimisation que j'applique systématiquement. Et non, je ne suis pas tjrs d'accord avec les manuels, désolé Ces règles sont issus de mon expérience, de ma connaissance des SGBD ou de le littérature. Parmis ces règles : je ne met jamais un index sur un champ de type TEXT. Tant pis si je ne suis pas d'accord avec le manuel. Mon cycle d'optimisation est assez simpliste : 1. Je conçois mon modèle en m'imposant des règles strictes. 2. J'optimise en phase de dév, en fct° des requêtes dont j'ai besoin. Cette optimisation va porter essentiellement sur : => La syntaxe des requêtes SQl => L'ajout de nouveaux index. 3. Je met mon modèle à l'épreuve de la production. C'est en recherchant les goulots d'étranglement que je vais mettre à l'épreuve mes règles initiales et les faire évoluer. Ensuite, il est vrai que dans mes choix je ne suis pas tjrs d'accord avec la majorité des développeurs. Mais ça c'est pas très grave. Deux exemples concret de choix techniques où je ne suis pas d'accord avec la grande majorité des développeurs : - L'indexation FULLTEXT : Je n'utilise jamais un SGBD, pour les recherches FULLTEXT. J'estime que les systèmes ne sont pas assez performant. - La modélisation d'une arborescence : je ne modélise jamais une arborescence par auto-jointure ( Merci, M. Celko ) . Tant pis, si la grande majorité des développeurs choisissent systématiquement le modèle par auto-jointure et ne sont pas d'accord avec moi.

Cela n'est pas une bonne idée. En règle générale, on n'utilise jamais d'index FULLTEXT, on utilise des index. On ne met jamais d'index sur un champ de type TEXT ou sur un BLOB. Si on veut indéxer un champ de type TEXT, on utilise FULLTEXT et des requêtes du type MATCH...AGAINST. Le fait de doubler ( Index + FULLTEXT ) sur la même colonne ne sert à rien. C'est peut-être même contre-performant. L'optimisation dépend de l'utilisation que tu fait de la colonne dans tes requêtes.

Désolé, je n'ai donc absolument rien compris à ton pb.

Nous utilisions des développement en interne.

Ton index ce n'est pas un index FULLTEXT ? Pourquoi ne pas dropper ton index actuel et le remplacer par un index fulltext. Ensuite tu refais un explain pour t'assurer qu'il est bien utiliser. Les index ne sont pas systématiquement utilisé. D'ailleurs je ne suis pas sur qu'ils soient utilisé avec des requêtes de type LIKE et %. Je fait un copier/coller d'un post que je viens de faire en face

Salut, Je viens juste de me rendre compte que tu avais posté ton schéma. J'ai jeté un coup d'oeil ( je dois avouer un coup d'oeil rapide ), ça à l'air bc plus correct que la première fois. Tes noms de clés étrangères sont parfois un peu long à mon goût ( domaine_utilisateur_profil_id_profil ), mais bon c'est pas très grave.

il faudrait tester ta variable RecordId pour t'assurer que le paramètre est bien passé. Tu as un lien vers le script que tu utilises ? Je jetterai un coup d'oeil

Ton pb n'est pas au niveau SQL mais bien au niveau Php : $recordID = $_GET['recordID']; La réception du paramêtre recordID n'est pas testé. Je suis pas un spécialiste de l'injection SQL, mais j'ai pas l'impression que l'appli soit trés sécurisé. Imaginons le bout de code suivant : /lapage.php?recordID=1;DELETE * FROM inscription => Suppression de 10 enregistrement dans la table inscription.

la requête porte sur la table inscription. Le champ auquel tu fait référence est dans la table an_membre. Avec une erreur sur le champ l'erreur serait plutôt du type : Unknown column 'idmembre' in 'field list' en tout cas le bout de code php, ça sent fortement le pager automatique généré par dreamweaver si tu t'y connais en php tu pourrais peut-être afficher las requête sur ta page et nous la poster : mysql_select_db($database_connexion, $connexion); $recordID = $_GET['recordID']; $query_DetailRS1 = "SELECT * FROM inscription WHERE id_membre = $recordID"; $query_limit_DetailRS1 = sprintf("%s LIMIT %d, %d", $query_DetailRS1, $startRow_DetailRS1, $maxRows_DetailRS1); $DetailRS1 = mysql_query($query_limit_DetailRS1, $connexion) or die(mysql_error()); $row_DetailRS1 = mysql_fetch_assoc($DetailRS1); Il faut juste rajouter ce bout de code : echo $query_limit_DetailRS1; avant : $DetailRS1 = mysql_query($query_limit_DetailRS1, $connexion) ....

Tu pourrais poster la requete qui pose pb ?

Site Centric Vs User Centric

Un début de réponse sur les requêtes multi-base dans ce post http://www.webmaster-hub.com/index.php?showtopic=23124&hl=

On discutait justement de ça hier apm. Il semblerait que cela existe chez Oracle. Sinon, comme le dit Anonymus, il faudrait écrire un parser générique faisant le mapping entre les "types" XML et les types SQL. Cela a de l'intérêt si les données de tes flux XML ont une struture relationelle.

En terme de performance quasiment aucune. Les optimiseurs SQL font bien leur boulot aujourd'hui. Par contre il existe une différence de sens - count(*) : compte la cardinalité d'une table. Le nombre de ligne de la table ou de la requête. Sauf erreur de ma part, c'est ce que voulait faire Tizel. Donc je lui ai conseillé de mettre count(*) - count( [DISTINCT|ALL] expression ) : Compte le nombre d'expression connu. Donc, après avoir enlevé les valeurs NULL. - Sur une clé primaire : count(*) et count(primary_key) sont strictement équivalent. Par habitude, je m'impose comme règle d'utiliser count(*) si je veux compter les lignes et pas count(primary_key)

Ma réponse est fausse les GROUP BY ne sont pas autorisés dans les UPDATE. Elle me plaisait pas trop cette requête UPDATE [LOW_PRIORITY] [IGNORE] tbl_name SET col_name1=expr1 [, col_name2=expr2 ...] [WHERE where_condition] [ORDER BY ...] [LIMIT row_count] Fait deux requêtes : - Un SELECT pour récupérer ton count(*) - Ton update derrierre

tu fait un count() sans faire de group by. Note : faire un count(*) plutot que count(nom_de_champ) Un truc du style, sans aucune garantie. : UPDATE dc_post, dc_comment SET nb_trackback=count(dc_comment.nb_trackback) WHERE dc_comment.comment_pub=1 & dc_comment.comment_trackback=1 & dc_comment.post_id=dc_post.post_id GROUP BY dc_comment.post_id

ça c'est une bonne nouvelle.

C'est quoi cette info ? Tu couple le SGBD que tu veux avec IIS. Pour MSDE, c'est effectivement une version gratuite. Cette version sert en développement, mais surtout pas en production.

Si tu veux réussir une migration d'un SGDB vers un autre, il faut l'anticiper. 1. Commence par modéliser tes bases de données. Passe par un outil comme PowerAMC 12, tu as une période d'éssai de 15 jours. MCD->MPD-> Génération de script de DB. N'hésite pas à générer des scripts pour +sieurs SGBD : mySQL, postgreSQL, SqlServer, Oracle, DB2, etc.... Garde les au chaud, on sait jamais. Si ton service explose et que tu as besoin d'un oracle 1. Bis Dans la mesure du possible, n'utilise aucune syntaxe SQL spécifique à un SGBD donné. Plus tu seras proche des standard SQL, plus la migration sera facile. 2. Découpe ton application en couche logique : dao/métier/présentation. Dans ta couche dao tu vas implémenter les fonctions ( ou objet ) d'accés aux données. tu auras une arbo du style : dao/mysql/*.php dao/pgsql/*.php dao/oracle/*.php etc... Ta couche métier fera appel aux fonctions/objet de ta couche dao sans jamais savoir quel est le mode de stockage derrière. Si tu réussis bien cette séparation, changer de SGBD reviendrat à réecrire une couche dao. Dans ton cas, tu n'as peut-être pas intérêt à passer par des outils d'abstraction d'accés aux SGBD ( style PEAR :: DB ). Ces outils sont géniaux pour te simplifier l'accés aux DB, par contre tu vas perdre en terme de performance. Dans un fichier Include tu définis ton path vers la bonne couche DAO. En théorie, la migration d'un SGBD consistera juste à modifier ce path. En théorie . 2. Bis Il faudrat prévoir des scripts de migration de données. ça devrait pas être le plus dur. 3. Ta couche métier. Pour simplifier la migration d'un SGBD vers un autre tu as tout intérêt a implémenter ta logique métier en dehors du SGBD. En clair : transférer les éventuelles procédures stockées du SGBD vers ta couche métier. Je suis pas tjrs d'accord avec ce point. Les procédures stockées ont l'avantages d'être plus performantes. ça c'est à voir en fct de ton projet et de tes habitudes de devs. 4 Optimisation des performances : Pour la mise en place d'un outil statistique tu as tout intérêt à séparer le stockage de tes données dans deux bases séparées : - Premiere base ( DBLog ) : la base de recueil des informations - Deuxième base ( DBStat ) : la base de consolidation des données. Cette séparation te permettra, le jour où tu en auras besoin, de mettre tes deux bases sur deux serveurs différents, sans trop de pb. Ces deux bases ont des spécificités totalement opposées : - DBLog : sera quasi exclusivement en écriture - DB Stats : sera quasi exclusivement en lecture - DBLog : Tu ne met aucun index sur cette base. Les index améliorent les performances des SELECT. Ils ralentissent les opérations d'INSERT et d'UPDATE. - DBStat : Tu use et abuse des index dans cette base pour optimiser les opérations de lectures. DBLog sert à recueillir les stats en temps réels. Chaque nuit tu passes tes scripts de consolidation qui vont transférer les données de DBLog vers DBStats. Chaque matin tes clients auront leurs stats dispo. 5. Quelle solution de stockage Petite réflexion perso : Est-ce qu'un SGBD est la meilleure solution de stockage pour un outil statistique ? Les SGBD sont performant sur des modèles de données relationnes ? Les statistiques sont-elles des données relationnelles ? La phase de consolidation dans un SGBD => Ok, cela pourrait simplifier l'implémentation du projet. La phase de Log => Est-ce qu'un SGBD est vraiment la structure la plus performante pour logger des stats ? Est-ce qu'un système de fichier ne serait pas plus performant ? Comment font xiti, eStat et les autres pour recueillir leurs données ?

Très honnêtement, si ton projet devient important, un forum n'est pas le meilleur endroit pour choisir un SGBD. Il va falloir que tu fasses une liste de ce qui est important pour toi, et comparer les différents outils du marchés. Je connais assez bien les SGBD mais je me risquerai certainement pas à te conseiller tel ou tel produit.

create table IF NOT EXISTS foo ( bar varchar(32));

pour mysql tu vas utiliser un outil comme mysqlWorkBench qui va te permettre de faire du reverse engeneering a partir de ta DB