Skip to content

Fiche duckdb: changements de structure liés à #560#585

Open
Lagaims wants to merge 16 commits into
InseeFrLab:mainfrom
Lagaims:dev-560
Open

Fiche duckdb: changements de structure liés à #560#585
Lagaims wants to merge 16 commits into
InseeFrLab:mainfrom
Lagaims:dev-560

Conversation

@Lagaims

@Lagaims Lagaims commented Jun 17, 2026

Copy link
Copy Markdown

Mise à jour de la fiche duckDB :

@JulienBlasco JulienBlasco marked this pull request as draft June 17, 2026 14:18
@Lagaims Lagaims marked this pull request as ready for review June 17, 2026 17:27
@Lagaims Lagaims marked this pull request as draft June 17, 2026 17:30
Comment thread 03_Fiches_thematiques/Fiche_duckdb.qmd Outdated
Comment thread 03_Fiches_thematiques/Fiche_duckdb.qmd Outdated
GROUP BY REG") # Utilise de la mémoire

Pour un usage basique en syntaxe `dplyr`, passer par `arrow` (au lieu de SQL) est plus facile à manipuler, notamment quand on souhaite ajouter des options telle que le partitionnement.
# Créer une vue dans la base de données DuckDB (Recommandé)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

J'aime bien les vues aussi, je trouve que c'est top pour la lisibilité. Donc j'aimerais bien qu'on puisse recommander mais j'ai un doute.

Est-ce qu'il y a pas un risque, dans certaines situations, de perte en performance ? Je crois, pas exemple, que les vues mettent pas en cache les données issues de requête HTTP ce qui, pour de grosses bases, va impliquer de retélécharger ces données à chaque requête.

Est-ce que je me trompe ? Si oui alors pas de souci pour recommander. Si non, je pense qu'il faut modérer la recommandation avec un petit truc du type

Suggested change
# Créer une vue dans la base de données DuckDB (Recommandé)
# Créer une vue dans la base de données DuckDB
Les vues permettent de faire référence à une table de données, résultat d'une requête simple comme complexe, sous la forme d'un nom. C'est une pratique qui rend le code plus lisible et ainsi s'avérer très utile. Cependant, pour de grosses bases de données, les vues rendent plus complexes les optimisations mises en oeuvre par DuckDB ce qui peut ralentir le code. Il y a donc un compromis à trouver, selon la taille de la base et la fréquence d'appel aux vues, entre lisibilité et performance.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tu as raison, je me suis un peu emballée. Je pense qu'un petit schéma vaut mieux que 1000 mots pour ce sujet :
image

Qu'en penses-tu ? Je trouve que ça résume bien les cas d'utilisation de TABLE et VIEW, et derrière on peut préciser qu'il faut préférer VIEW dès que c'est possible.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

très bonne idée!

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

J'ai pris en compte tes suggestion et ajouté le schéma, je pense que le lecteur comprend bien les bénéfices et les limites d'utiliser les VIEW

@linogaliana linogaliana changed the title Dev 560 Fiche duckdb: changements de structure liés à #560 Jun 18, 2026
@linogaliana

Copy link
Copy Markdown
Contributor

Merci @Lagaims pour cette proposition. J'ai pas tout lu (la fiche est loooongue) mais j'ai mis ci-dessus deux commentaires / suggestions

@Lagaims Lagaims marked this pull request as ready for review June 19, 2026 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants