Discussion :

[Astak]

Bonjour,

Pour une petite application (c++), j'ai besoin de stocker quelques données, et mon choix s'est porté vers SQLite (J'ai quelques connaissances Oracle/MySQL/MSSQL) pour la simplicité d'accès et d'écriture en comparaison à un simple stockage "brut" avec des traitements d'extraction de string etc...
Bref, du coup, on m'a longtemps dis que, sur une vraie base de données (client/serveur, et où le stockage des données dépassent la RAM disponible), l'architecture de la base est très importante , comme par exemple, ne pas créer de table surdimensionnées (en terme de nombre de colonnes), mais préféré plusieurs tables avec relations entre elles.

Mais pour le cas d'une petite base SQLite, est-ce que ce genre de raisonnement tient toujours ?

Dans mon cas, j'ai :
- une table de 800 lignes maximum avec 16 colonnes
- une table d'environ 3000 lignes avec 15 colonnes

Mon problème sur la seconde table, c'est qu'elle n'est pas complète, il y a au total 86 colonnes que je devrais rajouter.
Pour une si petite base, de quelques MO qui n'évoluera que très peu, est-ce plus performant de faire une table de +100 colonnes () ou est-il préférable que je fasse 2 autres tables de 40 colonnes et 46 colonnes avec lesquelles je pourrais faire des join avec ma table de base de 15 colonnes ?

J'espère que c'est assez clair...
Merci d'avance !

[SQLpro]

Les SGBDR fonctionnement tous de la même façon, donc les règles de bonnes pratiques sont les mêmes. La particularité de SQL lite est d'être MONO utilisateurs. C'est marqué dans le doc, et la doc recommande de ne pas l'utiliser s'il y a des utilisateurs concurrents.
En gros SQL Lite se limite à de l'embarqué, c'est à dire qu'un seul process accède à la base (par exemple pour une montre connecté, un smartphone, ou un frigo intelligent...)
Pour une application de gestion quel qu'elle soit, si de multiples utilisateurs y accèdent, la concurrence n'étant pas géré de manière efficace, vous pouvez avoir :

• des attentes
• des blocages
• des verrous mortels
• des mises à jour incohérentes

A +

[Astak]

Merci pour ta réponse.

Dans mon cas, l'application se basera sur les données présentes dans la base SQLite pour alimenté tout un tas de champ en fonction de certains critères, mais elle sera bien mono utilisateur.
Chaque utilisateur aura une copie de la base avec le logiciel.

Mais est-ce surdimensionné (ou même aberrant) de créer une table d'environ 100 colonnes en sachant que la base ne fera que quelques Mo (peut-être 5/10Mo) ?

Je ne suis pas développeur professionnel, ni même DBA, c'est un petit projet personnel pour une "petite" communauté, mais quitte à faire un travail, j'aimerai le faire le mieux possible.

Encore merci.

[SergioMaster]

Bonjour,

la taille d'une base SQLite peut faire jusqu'à 140 T donc coté taille c'est plus le support qui limitera la taille de la base.
une autre limite la taille du cache de récupération des données (2 M par défaut et 1 M sous Androïd)
tout est expliqué ici https://www.sqlite.org/limits.html

extraits
The default setting for SQLITE_MAX_COLUMN is 2000.
SQLITE_MAX_SQL_LENGTH which defaults to 1000000.
SQLite does not support joins containing more than 64 tables.
etc...

[Astak]

Ah merci pour le lien !
Bon, par défaut 2000 colonnes... du coup avec mes 100 colonnes je devrais pas avoir de soucis de performances pour une si petite application/base !

Encore merci à vous deux, bonne journée !

[SQLpro]

Ah merci pour le lien !
Bon, par défaut 2000 colonnes... du coup avec mes 100 colonnes je devrais pas avoir de soucis de performances pour une si petite application/base !

Encore merci à vous deux, bonne journée !

Soucis de performance peut être pas. Soucis d'écriture de requête, probable.

Et le jour ou vous voudrez faire une base consolidée de ces petites bases, vous serez dans la merde.

Donc, modélisez correctement au départ, cela vous évitera bien des problèmes futurs !

A +