Spidetra
-
Compteur de contenus
326 -
Inscrit(e) le
-
Dernière visite
Messages postés par Spidetra
-
-
Par contre pour une recherche de chaque mot et non la phrase entière le seul moyen est un simple WHERE LIKE %$Terme% simplement y'a-til moyen d'être plus performant sur cette requète qui ne passe forcèment par auncu index (EXPLAIN à l'appui).
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 ) :
The following examples demonstrate some search strings that use boolean full-text operators:*
'apple banana'
Find rows that contain at least one of the two words.
*
'+apple +juice'
Find rows that contain both words.
*
'+apple macintosh'
Find rows that contain the word apple, but rank rows higher if they also contain macintosh.
*
'+apple -macintosh'
Find rows that contain the word apple but not macintosh.
*
'+apple ~macintosh'
Find rows that contain the word apple, but if the row also contains the word macintosh, rate it lower than if row does not. This is softer than a search for '+apple -macintosh', for which the presence of macintosh causes the row not to be returned at all.
*
'+apple +(>turnover <strudel)'
Find rows that contain the words apple and turnover, or apple and strudel (in any order), but rank apple turnover higher than apple strudel.
*
'apple*'
Find rows that contain words such as apple, apples, applesauce, or applet.
*
'"some words"'
Find rows that contain the exact phrase some words (for example, rows that contain some words of wisdom but not some noise words). Note that the " characters that enclose the phrase are operator characters that delimit the phrase. They are not the quotes that enclose the search string itself.
-
Simplement Mamat veut pouvoir faire une requête qui soit "optimisée" (SELECT WHERE) en ayant un modèle qui est optimisée pour une autre utilisation (FULLTEXT)...
...
mais si tu en as une autre faut pas hésiter
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
On peut tout à fait faire le parallèle avec les arbres, l'utilisation du modèle Adjacent (auto-jointures) est tout à fait justifiable dans le cas où les accès (consultations) à l'arbre sont moins fréquents que la modification de sa structure...sinon un modèle pré-ordré (intervallaire) sera préconisé (jutilise plus souvent cette solution, car sur le Web on a tendance à rencontrer plus de systèmes ou la consultation est ce qui doit se faire le plus rapidement possible)...<{POST_SNAPBACK}>
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. -
Si tu veux vraiement faire cette requête essaie, peut-être, de définir un INDEX (normal) en plus de l'index FULLTEXT que tu as déjà pour les champs sur lesquels tu effectues la recherche.
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.
Les champs sur lesquels il y a un INDEX sont optimisé selon le manuel...je ne sais pas si c'est toujours le cas lorsqu'il existe déjà un un index FULLTEXT...<{POST_SNAPBACK}>
L'optimisation dépend de l'utilisation que tu fait de la colonne dans tes requêtes.
-
Heu oui je sais tout ça... je l'ai dit dans mes deux premiers post, l'index en fulltext est là depuis des années, mais pour qu'une requete where l'utilise il faut utiliser "martch ... against", donc avec mon expression ce n'est pas possible, vois-tu ?
<{POST_SNAPBACK}>
Désolé, je n'ai donc absolument rien compris à ton pb.
-
Nous utilisions des développement en interne.
-
Mais l'index y est déjà ! J'était persuadé que sur un simple SELECT avec WHERE, l'index fulltext n'était pas pris.... Je viens de vérifier en effet avec EXPLAIN il n'utilise pas l'index, d'où l'inefficacité de cette méthode...
<{POST_SNAPBACK}>
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
Ensuite il faut être prudent. Il ne sert à rien d'indéxer, si on utilise pas les index dans les requêtes.Un exemple concret :
ng int,
nd int,
KEY idx_ng (ng)
Deux champs de type int et un index sur le champ ng.
Si tu fait cette requête :
WHERE nd - ng = 1
ton index sur ng ne sera pas utilisé.
Il faut réécrire ta requête pour bénéficier de l'index sur ng.
WHERE ng = nd - 1
-
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.
-
message d'erreur
dans SQL
Excuse mon ignorance mais alors que dois je inscrire?<{POST_SNAPBACK}>
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
-
message d'erreur
dans SQL
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.
-
message d'erreur
dans SQL
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) ....
-
message d'erreur
dans SQL
Tu pourrais poster la requete qui pose pb ?
-
-
Un début de réponse sur les requêtes multi-base dans ce post
-
Bonjour,
Les dtd sont en général assez bien détaillées, je me demandais s'il n'existerait pas des traducteurs, ou convertisseurs qui prendraient d'un coté une dtd, pour la convertir en fichier sql pour insérer dans une base de données,
merci d'avance.
<{POST_SNAPBACK}>
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 -
Le nombre d'accès simultané n'est plus limité comme dans MSDE.
<{POST_SNAPBACK}>
ça c'est une bonne nouvelle.
-
Et pour tout dire c'est le seul moyen d'installer une base SQL sur un serveur IIS, c'est la version MSDE je crois qui est presque bon marché ;oD
<{POST_SNAPBACK}>
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
Libération de MYSQL...
dans Le salon de Webmaster Hub
Posté
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.