Discussion :

[jouclar]

Bonjour à tous,

J'ai besoin d'aide dans la compréhension du fonctionnement de SQLITE.

Je stock les valeurs contenues dans des fichiers cvs dans une base SQLite la somme des fichiers csv fait 125 Mb tandis que la taille de la base fait 235 Mb, je n'ai pas d'index dans la base.

Pourquoi un tel écart ?



Merci

[acaumes]

Bonjour,

Il faudrait voir comment est constitué ton fichier mais quelques pistes:

* Une colonne vide prendra plus de place (au moins un octet)
* Si tu n'as pas de clé primaire auto incrémentée SQLITE crée une colonne "rowid"
* L'encodage des textes (Ansi pour UTF)

Mais je trouve quand même le rapport important. Sur une de mes bases avec un index, je passe de 264 Mo à 330 Mo (soit +25% avec un index) alors que tu en es à 88%

As tu réorganisé ta base (commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

VACUUM

Cordialement

[jouclar]

Merci pour ces pistes acaume.

J'ai effectivement fait un VACUM

Quelques précisions sur le contenu de la base. Il y a 5 tables
* table 1 : 98 champs, pas de clefs primaire, 147254 enregistrements
* table 2 : 98 champs, 117970 enregistrements
* table 3 : 15 champs, 1 clef primaire, 19 champs
* table 4 : 7 champs, 1 clef primaire, 17 enregistrements
* table 5 : 32 champs, pas de clef primaire, 26121 enregistrements


le rapport entre la somme des fichiers csv que j'injecte dans la base et la taille de la base me semble disproportionné (proche de x2), mais c'est peut-être normal ?

[ed73170]

* table 1 : 98 champs, pas de clefs primaire, 147254 enregistrements
* table 2 : 98 champs, 117970 enregistrements

Moi je chercherais de ce coté, surtout si la totalité des 98 champs de chaque table n'est pas remplie. Et quoiqu'il en soit, 98 champs dans une table ce n'est pas une bonne idée, il y a probablement moyen de séparer ces tables en plusieurs plus petites.

A ce sujet tu peux voir cet article : http://blog.developpez.com/sqlpro/p1...mances_petites

[SergioMaster]

Bonjour,

Moi je chercherais de ce coté, surtout si la totalité des 98 champs de chaque table n'est pas remplie. Et quoiqu'il en soit, 98 champs dans une table ce n'est pas une bonne idée, il y a probablement moyen de séparer ces tables en plusieurs plus petites.

Je ne vois pas pourquoi. Et petite précision avec SQL on parle plutôt de colonnes que de champs.

Perso, bien que je ne maitrise pas SQLite, je pense plutôt à des transactions mal fermées

[jouclar]

Bonjour SegioMaster

Merci pour cette piste mais comment est-il possible de vérifier si une transaction est bien ou mal fermée ?

J'utilise un code en Python pour peupler la base, exemple ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
with open(data_file, 'rt') as csvFile: #  
     csvReader = csv.DictReader(csvFile, delimiter=';')
     with sqlite3.connect(db_filename) as conn:
            cursor = conn.cursor()
            cursor.executemany(sql, csvReader)
     cursor.close()
     conn.close()

que j'ai adapté à partir de https://pymotw.com/2/sqlite3/

[SergioMaster]

Merci pour cette piste mais comment est-il possible de vérifier si une transaction est bien ou mal fermée ?

ne connaissant pas ce serpent sauf de nom je serai bien en peine dire ce qui se passe au niveau de l'instruction cursor.executemany(sql, csvReader)pour ce qui est de SQlite même chose, je n'utilise que très peu (uniquement pour des tables de travail pour l'instant, donc volatiles)
je pense qu'avec SQLite il doit y avoir un moyen de vérifier, ou à tout le moins de 'réconcilier' toutes les transactions à moins qu'il s'agisse de ce que fait VACUMM ?

[ed73170]

Perso, bien que je ne maitrise pas SQLite, je pense plutôt à des transactions mal fermées

Avec SQLite les transactions sont implicites, c'est à dire que toute commande SQL autre que SELECT ouvre une transaction et la ferme une fois la requête entièrement exécutée car aucune modification de la base ne peut-être réalisée en dehors d'une transaction (voir la documentation SQLite https://www.sqlite.org/lang_transaction.html). Il ne peut donc pas y avoir de transaction mal fermée si on utilise ce mode.

Il est bien sûr possible d'utiliser des transactions manuelles avec BEGIN et END (ou COMMIT), mais vu le code posté par jouclar, cela ne semble pas être le cas.

[jouclar]

J'ai avancé sur mon problème.

Sur chacune les deux plus grosses tables de la db initiale, j'ai supprimé la colonne id puis nettoyer la base via un VACUM et ma base passe de 246Mo à 84Mo génial sauf que je ne sais pas pourquoi ??