Les bases de données SQL ne se limitent pas à MySQL. Il faudrait voir ce que cela donne avec un moteur moins limité (qui supporte MINUS, avec un optimiseur plus poussé).
Et cette requête particulière peut être écrite de nombreuses manières, ce qui ne donnera pas la même chose en temps de traitement (en fonction de la répartition des données, des index, etc…). Le MINUS n'est pas forcément lent (je me souviens d'une requête de ce style sur 5 millions de lignes, avec une dizaine de tables jointes, que le dba avait réécrite avec MINUS ; elle était passé de plusieurs heures à quelques minutes… il y a 8 ans)
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. Je pense que là où se trouve la faiblesse des SGBDR, c'est qu'il faut les compétences qui vont avec (côté concepteurs, développeurs, DBA). Je ne connais pas les bases NoSQL, donc je ne sais pas du tout si c'est pareil.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par Flo . En réponse à la dépêche Petit état des lieux du NoSQL. Évalué à 1.
Les bases de données SQL ne se limitent pas à MySQL. Il faudrait voir ce que cela donne avec un moteur moins limité (qui supporte MINUS, avec un optimiseur plus poussé).
Et cette requête particulière peut être écrite de nombreuses manières, ce qui ne donnera pas la même chose en temps de traitement (en fonction de la répartition des données, des index, etc…). Le MINUS n'est pas forcément lent (je me souviens d'une requête de ce style sur 5 millions de lignes, avec une dizaine de tables jointes, que le dba avait réécrite avec MINUS ; elle était passé de plusieurs heures à quelques minutes… il y a 8 ans)
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. Je pense que là où se trouve la faiblesse des SGBDR, c'est qu'il faut les compétences qui vont avec (côté concepteurs, développeurs, DBA). Je ne connais pas les bases NoSQL, donc je ne sais pas du tout si c'est pareil.