Je rappelle que le fond de ma remarque n'était pas de critiquer SQL, mais de montrer qu'un stockage relationnel fiable et cohérent n'était pas toujours adapté à la recherche des données.
Les vues matérialisées ou les tables mises à jour par cron peuvent être une solution, mais on n'atteindra pas la puissance d'une solution de recherche dédiée. Il me semble plus "rentable", pour opitmiser la recherche, de greffer Sphinx Search sur sa base relationnelle plutôt que de la partitionner.
Quant aux requêtes proposées, la première n'est pas possible en MySQL (pas de "MINUS"). Je doute qu'elle soit efficace, mais j'admets que je me base sur une impression.
Pour la seconde, AMHA elle me semble complètement fausse en l'état. Ce qui prouverait que la requête nécessaire est complexe. J'aurais écris qqchose comme :
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 3. Dernière modification le 09 mai 2012 à 14:17.
Je rappelle que le fond de ma remarque n'était pas de critiquer SQL, mais de montrer qu'un stockage relationnel fiable et cohérent n'était pas toujours adapté à la recherche des données.
Les vues matérialisées ou les tables mises à jour par cron peuvent être une solution, mais on n'atteindra pas la puissance d'une solution de recherche dédiée. Il me semble plus "rentable", pour opitmiser la recherche, de greffer Sphinx Search sur sa base relationnelle plutôt que de la partitionner.
Quant aux requêtes proposées, la première n'est pas possible en MySQL (pas de "MINUS"). Je doute qu'elle soit efficace, mais j'admets que je me base sur une impression.
Pour la seconde, AMHA elle me semble complètement fausse en l'état. Ce qui prouverait que la requête nécessaire est complexe. J'aurais écris qqchose comme :