L'exemple de modèle que tu donnes me paraît justement le cas où un SGBD relationnel s'en sort bien en général.
Pourtant, tout ce que tu as écrit me conforte dans ma position. Pour rappel, elle est de séparer les bases de stockage et de recherche.
Tu dis qu'il faudrait changer de moteur de SGDBR, tester plusieurs syntaxes SQL en fonction d'une multitude de paramètres, et qu'alors on trouvera sans doute une requête plus rapide (avec en exemple une requête qui prenait quelques minutes). Or justement j'écrivais : « On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel. »
La requête optimale pour un cas particulier ne m'intéresse pas souvent. En général, j'ai un formulaire de recherche (web, ou dans un client lourd, voire des paramètres CLI) et je dois générer la requête automatiquement. Oh, rien de bien méchant, ce ne sont souvent que 2 ou 3 champs de recherche textuelle, et 5 ou 6 filtres sur des paramètres numériques. Du genre : les posts contenant les mots [A], avec un tag dans [B], mais sans tag parmi [C], et publiés dans une des catégories [D] mais pas [E], etc, etc. Générer le SQL optimal (en supposant qu'on a déjà les bons indexes et tous les paramètres optimaux du serveur) ne sera pas une mince affaire, surtout si on veut une réponse dans la seconde. Alors que si on stocke les données "cherchables" dans une base NoSQL dénormalisée dédiée à la recherche, type Lucene ou Sphinx Search, la requête sera triviale à construire, et quelques millions d'attributs n'empêcheront pas une réponse en une fraction de seconde.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 1.
Pourtant, tout ce que tu as écrit me conforte dans ma position. Pour rappel, elle est de séparer les bases de stockage et de recherche.
Tu dis qu'il faudrait changer de moteur de SGDBR, tester plusieurs syntaxes SQL en fonction d'une multitude de paramètres, et qu'alors on trouvera sans doute une requête plus rapide (avec en exemple une requête qui prenait quelques minutes). Or justement j'écrivais : « On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel. »
La requête optimale pour un cas particulier ne m'intéresse pas souvent. En général, j'ai un formulaire de recherche (web, ou dans un client lourd, voire des paramètres CLI) et je dois générer la requête automatiquement. Oh, rien de bien méchant, ce ne sont souvent que 2 ou 3 champs de recherche textuelle, et 5 ou 6 filtres sur des paramètres numériques. Du genre : les posts contenant les mots [A], avec un tag dans [B], mais sans tag parmi [C], et publiés dans une des catégories [D] mais pas [E], etc, etc. Générer le SQL optimal (en supposant qu'on a déjà les bons indexes et tous les paramètres optimaux du serveur) ne sera pas une mince affaire, surtout si on veut une réponse dans la seconde. Alors que si on stocke les données "cherchables" dans une base NoSQL dénormalisée dédiée à la recherche, type Lucene ou Sphinx Search, la requête sera triviale à construire, et quelques millions d'attributs n'empêcheront pas une réponse en une fraction de seconde.