Mes données liées à des nœuds ou feuilles d'un arbre et je veux pouvoir faire une recherche en filtrant sur un nœud en espérant trouver toutes les entrées liés à ce nœud ou a sa descendance.

Mes données sont donc

* id_ressource
* id_category
* ...

Et j'ai un arbre stocké dans une structure classique

* id_category
* id_category_parent
* ...

 1    null
 2    null
 3    1
 4    3
 5    3
 6    2
 7    6
 8    6

Solution 1.

J'indexe les données sans me préoccuper de l'arbre, juste en stockant l'id_category d'appartenance.

Lorsque que je veux chercher un nœud, je récupère la liste de ses enfants et puis je cherche tous les objets appartenance à un de ces catégories

donc pour la catégorie 2

;filter:id_category,2,6,7,8

Le problème avec cette solution, c'est qu'avec un arbre imposant, on se retrouve avec des filtres très grands.

A l’initiative de SkySQL et LeMug.fr, Colin Charles de Monty Program viendra nous parler de MariaDB demain mercredi 1er février au Patricks Irish Pub à Paris à partir de 18h. Si vous souhaitez en connaître un peu plus sur ce fork de MySQL, n’hésitez pas !
Plus d’infos sur la page officiellle

• Sphinx 2.0.3 Release <- Ce n'est pas anodin C'EST UNE STABLE (la dernière stable c'est 0.9.9 en dec-2009)
• Calculating number of Connection to #MySQL | http://commandlinefu.com
• IndexTank real-time fulltext search designed to separate relevance signals from document text. (shares, likes, +1, RTs)
• Un petit post sur pour ce réveillon : Sphinx : Tri par titre en multi index ...
• Sphinx 2.0.3 released #search #oss

• Twitter : https://twitter.com/#!/Moosh_be
…

Dans le premier article, nous avons vu combien il était facile de solutionner des grilles de sudoku avec une seule requête SQL. Malheureusement, c’était trop beau pour être vrai…

Avant de poursuivre, voici un outil utile pour se faciliter la tâche.  Pour ceux qui utilisent Smalltalk, vous pouvez vous aider du script suivant :

| uneTableOuVue uneStringSudoku stream estLePremier |

uneTableOuVue := 'sudoku_rows_view'.
uneStringSudoku := '.........134825697759364182397182564.........581476239825641973976538421.........'.

stream := ReadWriteStream on: String new.
stream
nextPutAll: 'SELECT * '; cr;
nextPutAll: 'FROM ';
nextPutAll: uneTableOuVue;
space; cr;
nextPutAll: 'WHERE'; cr.

estLePremier := false.
1 to: 9 do: [:r |
1 to: 9 do: [:c | | i |
i := (r-1)*9 + c.
((uneStringSudoku at: i) ~= $. and: [(uneStringSudoku …

Ainsi donc, cette première partie détaillera la méthode de base utilisée pour résoudre un sudoku en une seule requête SQL.  Et en passant, pour ceux que la petite histoire intéresse, vous trouverez ici un excellent article sur l’évolution du sudoku.

Pour nous faciliter la tâche, nous utiliserons des tables de type MyISAM pour commencer.  Dans le prochain article, nous ferons aussi en sorte que notre méthode ne retourne qu’une seule grille valide même dans le cas où plusieurs solutions existeraient.  Rappelons que notre objectif ultime est d’optimiser une base de données dans le but bien précis de solutionner une grille valide dans des délais raisonnables.  Mais pour cet article, nous nous contenterons de verser dans la facilité!

Pour ceux qui voudraient se familiariser avec MySQL (ou tout simplement tester la version 5.6), il est possible de le faire en se créant gratuitement un compte sur le site db4free.net.  La procédure est simple et ne prend qu’une minute.

Prenez toutefois bonne note que les administrateurs du serveur se réservent le droit, à tout moment, de supprimer votre base de données et/ou votre compte.  Évidemment, cet avertissement s’adresse à ceux qui abuseraient de ce service gratuit.  Les requêtes monopolisant le CPU du serveur, les bases de données trop volumineuses et les comptes très rarement utilisés sont autant de raisons d’être concernés par l’avertissement ci-haut!

On peut accéder à sa (une seule par compte) base de données de trois façons :

1) par le client mysql avec la commande:

mysql …

1. Insérer du code

Pour ceux qui se demandent comment insérer des bouts de code dans WordPress.com, il faut savoir qu’il existe des tags permettant de le faire.  Plusieurs langages de programmation populaires sont supportés mais pas Smalltalk, malheureusement…  Pas encore du moins!  Pour ce qui est du code SQL, ça  fonctionne assez bien.  Ça va nous permettre d’afficher nos requêtes à MySQL de façon lisible et agréable à l’oeil!

La méthode est expliquée en anglais seulement mais les indications sont faciles à suivre.

Ça donne quelque chose du genre :

SELECT *
FROM region
INNER JOIN (
SELECT region.PDB, region.CHAIN
FROM region
LEFT JOIN split_domain USING (SUNID)
WHERE split_domain.SUNID IS NULL
GROUP BY PDB, CHAIN
HAVING COUNT(*)>1
) AS x
ON
region.PDB = …

"La simplicité est la sophistication suprême" (Léonard de Vinci).

Problème : vous avez à trouver, en seulement quelques secondes, un enregistrement unique parmi des milliards de milliards de possibilité et les seules informations dont vous disposez pour faire votre recherche sont de 17 à 35 attributs sur les 81 que contiennent la donnée tant convoitée… Est-ce possible ? Comment faire? De prime abord, ça semble impossible!

"Impossible n’est pas français" comme le dit le dicton (faussement attribué à Napoléon Bonaparte, vexé par le pessimisme de Jean Léonard, comte le Marois).

Il y a bientôt quelques années de cela, un de mes confrères de travail, …

Puisque sphinx ne connaît que des valeurs scalaires pour faire un tri alphabétique, il faut transformer les chaînes de caractères en nombre.

sql_attr_str2ordinal sert à ça.

Sauf que .... ce qu'on stocke c'est un n° d'ordre dans l'index, c'est pas une représentation numérique de la chaîne.

Le nom est bien 2ordinal et pas 2num

Pour confirmation cet extrait de la doc :

9.1.20. sql_attr_str2ordinal
(...)
When indexing ordinals, string values are fetched from database,
temporarily stored, sorted, and then replaced by their respective ordinal 
numbers in the array of sorted strings.
So, the ordinal number is an integer such that sorting by it produces
the same result as if lexicographically sorting by original strings.
by string values lexicographically.

Donc pour les …

Pour notre deuxième volet sur les points les plus importants à regarder lors de la configuration d’un serveur MySQL, nous allons nous occuper du cache de requêtes, de la réplication et de la journalisation. En route !

Cache de requêtes

Le cache de requêtes est une excellente idée des années 90 pour accélérer les performances des SELECT. Malheureusement ce cache n’est absolument pas scalable en terme de connexions simultanées, ce qui signifie que dans 99,9% des cas, les performances seront meilleures quand le cache est désactivée.

Par conséquent, le tuning du cache de requêtes est très simple, il vous suffit d’indiquer dans votre fichier de configuration :
query_cache = 0

Pour les plus curieux, sachez que la désactivation du cache de requêtes n’empêche pas le serveur d’utiliser la mutex d’accès au cache de requêtes : même désactivé, le cache de requêtes peut …