Je devais absolument tout typer avant d'importer, effacer les tables suivant les versions
Pour ça je me suis fait un script d'import Excel (qui pourrait être adapté pour du csv) qui lit une centaine de lignes du fichier pour essayer d'en déduire des types probables pour les différentes colonnes, puis qui crée la table correspondante ou qui remplit une table existante avec les données du fichier, en mettant à jour dynamiquement la liste des colonnes concernées dans l'insert en fonction des en-têtes de colonnes.
Pour la lecture plutôt que de passer par un ORM je crée aussi en dynamique des tuples nommés à partir des champs ramenés par une requête simple pour chaque table / requête utilisée. Par défaut ça fait un :
select * from table limit 1
mais pour certaines vues un peu chronophages j'écris à la main une requête ad hoc dont je sais qu'elle retourne vite (avec un where tapant dans un index typiquement). J'ai opté pour cette solution plutôt que de passer par des pragma car la fiabilité des pragma m'a joué des tours sur certaines vues.
Bon ça casse pas 3 pattes à un canard mais ça me fait gagner du temps quand je dois charger des nouveaux fichiers, ou des fichiers légèrement différents, ou que je renomme une colonne n'entrant pas dans une jointure : le code s'adapte dans un certain nombre de cas.
Après pour le fait de faire du python pour les calculs plus complexes je peux comprendre. J'ai une requête de 137 lignes dans une vue qui certes fait le boulot mais qui n'est pas des plus simples à maintenir.
[^] # Re: SQLite
Posté par Papey . En réponse au journal csvspoon et csvformatmail: l'industrialisation de la manipulation de fichiers csv.. Évalué à 1.
Pour ça je me suis fait un script d'import Excel (qui pourrait être adapté pour du csv) qui lit une centaine de lignes du fichier pour essayer d'en déduire des types probables pour les différentes colonnes, puis qui crée la table correspondante ou qui remplit une table existante avec les données du fichier, en mettant à jour dynamiquement la liste des colonnes concernées dans l'insert en fonction des en-têtes de colonnes.
Pour la lecture plutôt que de passer par un ORM je crée aussi en dynamique des tuples nommés à partir des champs ramenés par une requête simple pour chaque table / requête utilisée. Par défaut ça fait un :
mais pour certaines vues un peu chronophages j'écris à la main une requête ad hoc dont je sais qu'elle retourne vite (avec un where tapant dans un index typiquement). J'ai opté pour cette solution plutôt que de passer par des pragma car la fiabilité des pragma m'a joué des tours sur certaines vues.
Bon ça casse pas 3 pattes à un canard mais ça me fait gagner du temps quand je dois charger des nouveaux fichiers, ou des fichiers légèrement différents, ou que je renomme une colonne n'entrant pas dans une jointure : le code s'adapte dans un certain nombre de cas.
Après pour le fait de faire du python pour les calculs plus complexes je peux comprendre. J'ai une requête de 137 lignes dans une vue qui certes fait le boulot mais qui n'est pas des plus simples à maintenir.