Linkr
Accueil Ressources Outils Documentation Blog Démo
EN
  • Qu'est-ce que Linkr ?
  • Modes de déploiement
  • Démarrage rapide
  • Installation locale
  • Avec Docker
  • Installation manuelle
  • Client-only
  • Votre premier projet
  • Espaces de travail et projets
  • Le pipeline de données
  • Entités et partage
  • Versioning et collaboration
  • Vue d'ensemble
  • Projets
  • Wiki
  • Plugins
  • Membres et rôles
  • Paramètres
  • Schémas
  • Bases de données
  • Sous-bases dérivées
  • Qualité des données
  • Catalogue de données
  • Collections de scripts SQL
  • Pipelines ETL
  • Présentation
  • Projets d'alignement
  • Vue d'ensemble
  • Concepts cibles
  • Éditeur d'alignements
  • Suggestions
  • Évaluation
  • Export
  • Vue d'ensemble
  • Concepts
  • Cohortes
  • Données individuelles
  • Pipeline
  • Jeux de données
  • IDE
  • Applications web
  • Versioning
  • Vue d'ensemble
  • Onglets et widgets
  • Widgets intégrés
  • Widgets d'analyse
  • Cartes de contrôle (SPC)
  • Questionnaires et eCRF
  • Code R et Python
  • Filtres, paramètres et export
  • Vue d'ensemble
  • Mode présentation
  • Exporter un rapport
  • Agents
  • Fournisseurs de modèles
  • Skills
  • Créer du contenu via MCP
  • Import et export
  • Versioning git
  • Catalogue communautaire
  • Publier du contenu
  • Installation en production
  • Configuration
  • Authentification et permissions
  • Fichiers sur le serveur
  • Sauvegarde et restauration
  • Glossaire
  • Raccourcis clavier
  • Notes de version
Documentation Entrepôt de données Collections de scripts SQL

Collections de scripts SQL

Ranger, exécuter et partager les requêtes qui interrogent vos bases : l'éditeur, l'explorateur de schéma et les raccourcis.

En résumé

Une collection est un dossier de scripts SQL, rangés en arborescence et exécutés sur une base de l’entrepôt. L’éditeur exécute une sélection, un script ou toute la collection, avec un explorateur de schéma à côté. Comme toute entité Linkr, une collection s’exporte, se versionne et se publie.

Client Disponible en mode client-only — tout fonctionne dans le navigateur, sans backend. Backend Disponible avec le backend FastAPI.

Pourquoi ranger ses requêtes

Les requêtes qui interrogent un entrepôt existent déjà, en quantité. Elles sont simplement dispersées : réparties entre plusieurs dépôts git, parfois pas versionnées du tout, et surtout rarement mises en commun. Chaque équipe réécrit ce qu’une autre a déjà écrit.

Une collection les rassemble là où se trouvent les données. Elles s’exécutent sur la base concernée, elles portent un nom, et elles suivent le même chemin de partage que le reste — export, dépôt git, catalogue.

Ce n'est pas un outil de transformation

Une collection interroge. Elle ne fabrique pas de base et n’écrit nulle part : toutes les bases sont attachées en lecture seule. Pour alimenter une base à partir d’une autre, c’est un pipeline ETL.

L’éditeur

Trois zones : l’arborescence des scripts à gauche, l’éditeur au centre, les résultats en dessous. Un explorateur de schéma s’ouvre à la demande.

Les scripts se rangent en dossiers, comme des fichiers. Les fichiers .md sont acceptés eux aussi : une collection peut donc mêler requêtes et notes expliquant à quoi elles servent — et un fichier markdown s’affiche en rendu plutôt qu’en texte.

Exécuter

Quatre gestes, du plus fin au plus large :

ActionRaccourciCe qui part
Exécuter la sélectionCmd/Ctrl + EntréeLe texte sélectionné
Exécuter la ligne couranteCmd/Ctrl + EntréeLa ligne du curseur, quand rien n’est sélectionné
Exécuter le scriptBouton ExécuterLe fichier entier
Exécuter tous les scriptsCmd/Ctrl + Maj + EntréeToute la collection

Le même raccourci sert pour la sélection et pour la ligne : s’il y a une sélection, c’est elle qui part, sinon c’est la ligne du curseur. C’est la convention de RStudio, et elle rend la mise au point d’une requête longue beaucoup plus directe — on exécute un morceau de WITH sans découper le fichier.

Cmd/Ctrl + S enregistre. Un bouton dans la barre d’outils affiche la liste complète des raccourcis.

L’explorateur de schéma

Le panneau latéral liste les tables de la base active avec leurs colonnes, types et nullabilité, et une recherche. Deux boutons font gagner du temps :

  • Copier SELECT — met dans le presse-papier un SELECT listant toutes les colonnes de la table, plutôt que de les retaper.
  • Copier la référence du schéma — copie le préfixe qui désigne la base dans une requête.

Le second bouton n'apparaît qu'en mode navigateur

Et c’est normal. En mode navigateur, une base est attachée sous le nom ds_<identifiant>, utile pour une requête qui croise plusieurs bases. En mode serveur, ce préfixe n’existe pas : les scripts s’écrivent avec des noms de table nus. Le bouton est masqué plutôt que de proposer une référence qui ne fonctionnerait pas. Voir Bases de données.

Choisir la base

Une collection s’exécute sur une base à la fois, choisie dans la barre d’outils. La collection mémorise une base par défaut, modifiable à tout moment.

Cela veut dire qu’une même collection peut servir sur plusieurs bases du même modèle : des scripts de contrôle OMOP écrits une fois s’exécutent sur la base de production comme sur une copie de test, en changeant simplement la base active.

En mode serveur, un résultat est plafonné à 10 000 lignes

La requête s’exécute entièrement côté serveur, mais seules les 10 000 premières lignes redescendent vers le navigateur. C’est une protection : un SELECT * sur une table de plusieurs millions de lignes ne ramène pas tout l’entrepôt dans un onglet.

Pour un volume supérieur, agrégez côté SQL, ou passez par un jeu de données — qui, lui, est fait pour porter des tables entières.

Partager une collection

Une collection est une entité comme les autres : export ZIP, dépôt git, publication au catalogue, readme et licence. Son contenu est du texte, donc elle se versionne particulièrement bien — un git diff sur une requête se lit.

C’est le format naturel pour diffuser un jeu de requêtes : des contrôles OMOP, le calcul d’un score, les requêtes d’extraction d’une étude. Voir Entités et partage.

Pour aller plus loin

  • Bases de données — ce que les scripts interrogent, et comment les désigner.
  • Qualité des données — pour transformer une requête de contrôle en vérification rejouable.
  • Pipelines ETL — quand il faut écrire, et pas seulement lire.
  • IDE — pour une analyse en R ou en Python plutôt qu’en SQL.
PrécédentCatalogue de donnéesSuivantPipelines ETL

Produit

  • Accueil
  • Démo

Ressources

  • Documentation
  • Ressources
  • Outils
  • Blog

Communauté

  • Code source Framagit
  • Code source Github

À propos

  • InterHop.org
  • Contact

2021–2026 InterHop — CC BY-NC-SA 4.0 (site) · GPLv3 (logiciel)