Archives pour la catégorie Langage SQL (norme)

Pourquoi la clause ORDER BY… est-elle interdite au sein d’une requête ?

3 réponses

Certains développeurs pensent naïvement pouvoir mettre une clause de tri ORDER BY un peu partout dans une requête. Il n’est est rien. Une clause ORDER BY ne peut figurer que comme dernière lignes d’une requête de type SELECT. Même si vous pouvez parfois l’écrire à l’intérieur de certaines requêtes (certains SGBDR ne râlant même pas sur cette inadmissible faute) elle sera au mieux ignorée et au pire peut donner des résultats incohérent… Mais pourquoi ?
Lire la suite →

MySQL ? Un SGBDR poudre aux yeux !

109 réponses

Une critique objective mais sans pitié pour MySQL…Voici une liste non exhaustive des points pour lesquels je considère que MySQL est un ersatz de SGBDR C/S et qui peuvent poser problème, tant au niveau des performances des applications que de la qualité des données (certains résultats de requête sont mathématiquement faux). En fait, dès sa conception reposant directement sur l’OS, MySQL a été mal conçu. Parmi les principaux défauts de mySQL notons : la pauvreté de la gestion de la concurrence (en pratique les performances de MySQL chutent à plus de 5 utilisateurs en concurrence, alors que tous les autres SGBDR acceptent des centaines d’utilisateurs en parallèle sans broncher), la gestion plus que pauvre des transactions, des sauvegardes impossible à chaud, le manque de fonctionnalité des contraintes SQL, un SQL hors norme et très incomplet (près de 20 ans de retard – certaines requêtes étant infaisables avec MySQL), et pour couronner le tout, la destruction de certaines de vos données ! … bref un ensemble de problèmes édifiants pour un SGBDR qui se vante d’être le meilleur sans qu’aucun benchmark n’ai jamais étayé cette affirmation !
Lire la suite →

Filtre conditionnel sur le WHERE avec requête paramétrée… Comment ignorer en cas de NULL ?

8 réponses

Voici un cas de filtrage WHERE bien courant pour une requête paramétrée. Comment s’affranchir du filtre si le paramètre est NULL ? Soit l’on veut filtrer une colonne si le paramètre est valué, soit l’on veut toutes les lignes. Un bel exemple d’utilisation de COALESCE et de CASE.
Lire la suite →

MERCI de respecter les normes !

19 réponses

Je suis sidéré de voir de plus en plus de technocrétins (le mot n’est pas de moi…) prôner de faire sauter les normes et de vivre l’informatique dans l’anarchie. Voici une explication de l’extrême danger que représente le non respect des normes en informatique… Et je suis d’autant plus choqué de cette imbécilité que ceux qui exhorte à casser les normes se veulent des dignes représentant du logiciel libre ! Or il n’y a pas plus simple que l’anarchie pour devenir dépendant, donc enfermé et finalement prisonnier… Apprendre à vivre en société ne semble pas évident pour certains !
Lire la suite →

Introduction à l’administration des serveurs SQL (SGBD relationnels)

6 réponses

En avant première, voici un extrait d’un nouveau chapitre de notre livre sur SQL qui figurera dans la 4e édition, publiée cette année. En tout, deux nouveaux chapitres :
– l’indexation des bases de données
– une introduction à l’administration des SGBDR
C’est un extrait de ce dernier chapitre que nous vous offrons
Lire la suite →

Optimisation de requêtes SQL : « SARGABLE » c’est quoi ?

4 réponses

Le terme anglais « SARGABLE » indique si une expression de filtrage (prédicat) peut utiliser ou non une recherche dans un index. Si c’est le cas, le prédicat est dit sargable, l’index est utilisé pour une recherche et le temps de réponse sera excellent. Sinon, le temps de réponse sera mauvais car il faudra balayer toutes les lignes de la table pour satisfaire la dempande… Mais quelles sont les expressions « sargable », peut t-on transformer une expression non sargable en expression sargable ? Voici quelques questions et les réponses associées, avec des exemples sous MS SQL Server…
Lire la suite →

Base de données et performances… petites tables et tables obèses !

23 réponses

La plupart des développeurs sont persuadés que mettre toutes les informations dans une même table rendra leur base de données plus rapide… Et l’on voit apparaître dans la base de nombreuses tables de plusieurs dizaines de colonnes. C’est une vue à court terme, car dès que la base de données commence à croitre ou que le nombre d’utilisateur augmente, les performances deviennent vite catastrophique… Cet article explique pourquoi…
Lire la suite →