Les remarques finales
Merci d’avoir suivi jusqu’à la fin! J’espère que ce fut une lecture agréable et éclairante.
À ce stade, nous avons couvert la plupart des commandes et fonctions SQL importantes, mais j’espère que les plus grands points seront les techniques et l’heuristique pour penser aux requêtes. Parmi les plus importantes, on peut citer :
-
Comparer la forme des tableaux disponibles avec le résultat souhaité pour décider de l’agrégation à faire.
-
Examiner où se trouve l’information dont nous avons besoin. Est-ce dans une ligne adjacente? Ou un groupe? Ou tout l’ensemble de données ?
-
Interprétation des requêtes dans la bonne structure logique. Par exemple, voir les clauses comme étant essentiellement vrai ou faux; voir
<table1> JOIN <table2> ON ...comme une grande table.
D’aller plus loin dans son apprentissage de SQL, il vaut probablement la peine d’examiner les window functions (fonctions de fenêtrage) et les expressions courantes des tables. Vous pouvez reproduire leur comportement avec les techniques que vous avez apprises ici, mais elles facilitent la vie et vous présentent un nouveau paradigme précieux. J’ai omis ces concepts parce qu’au moment de la rédaction SQLite ne supportait pas les fonctions de fenêtre, et je voulais éviter la complexité d’une nouvelle base de données et du dialecte SQL.
Jusqu’à présent, nous n’avons appris que la consommation de données (l’exécution). Il existe tout un autre domaine du SQL pour manipuler les données. Ces actions concernent la création de tables, l’insertion et la suppression de données. Comprendre ces concepts peut être utile même si vous n’administrez pas de bases de données, car cela vous aide à comprendre, entre autres choses, pourquoi les tables sont structurées comme elles le sont.
Plus important encore, vous avez besoin de beaucoup de pratique pour devenir efficace sur les problèmes du monde réel. La section suivante présente quelques exercices mais la difficulté augmente fortement. Vous voudrez peut-être aller dans le monde et pratiquer ce que nous avons couvert jusqu’à présent et revenir quand vous serez prêt.
Les questions de défi
Les exercices des chapitres précédents ont été conçus pour réduire la complexité afin de créer un environnement propice. Ce chapitre marque la frontière dans le monde sauvage des problèmes SQL. L’idée ici est d’essayer par un baptême du feu – les questions sont optimisées pour l’utilité plutôt que pour la facilité de l’apprentissage. Même les rédacteurs SQL expérimentés peuvent avoir de la difficulté; et il y a beaucoup de valeur dans cette lutte.
La participation collective
De bons problèmes font ou cassent un tutoriel. Si vous avez une idée pour un nouveau problème ou section, je serais heureux de vous aider à le poster ici avec crédit complet allant à vous. Envoyez-moi un courriel à zichongkao@gmail.com ou soumettez une demande de tirage. Gardez à l'esprit que les bons problèmes ne sont pas nécessairement difficiles : ils mettent des techniques qui ont de nombreuses applications.
Le coparrainage du Sénat sur le jeu de données
Par Kao
Dans cette section, nous présentons un nouvel ensemble de données provenant de la 114e session du Congrès (2015-2016) compilé par James Fowler et d’autres. J’ai retravaillé l’ensemble de données pour nous permettre d’étudier les relations entre les sénateurs qui coparrainent.
Le sénateur qui présente le projet de loi est appelé le « parrain ». D’autres sénateurs peuvent manifester leur appui en coparrainant le projet de loi. Les cocommanditaires au moment de l’introduction sont appelés « cocommanditaires originaux » (source). Chaque ligne du tableau indique le projet de loi, le parrain, un coparrain original et les États représentés par les sénateurs. Notez qu’un projet de loi peut être coparrainé par plusieurs personnes.