SQLITE - requête SQL ou tri d'une List<>

Bonjour à tous,

Dans le cadre du développement d'une application desktop (de type industrielle), je mets en œuvre une base de données sqlite.

La base est peu conséquente. L'app dialogue avec un automate, j'ai donc potentiellement plusieurs transactions avec la base à réaliser toutes les 500ms.

A chaque fois je me pose cette question :

Faut-il mieux alimenter une List<> de manière globale (avec un SELECT * FROM...), puis effectuer des tri dans cette liste avec les méthodes associées.

Ou bien, faut-il mieux réaliser plusieurs transactions SQL pour arriver au même résultat ?

Je suppose qu'il n y'a pas de réponse universelle, mais comment m'orienter sur le choix au cas par cas ?

Merci à tous. Bonne journée.

Bonjour,

Je dirais que ça dépends, surtout si les conditions du SELECT sont bien ficelés.

En écriture, je t'aurai très largement conseillé de réduire au maximum les requêtes mais pour de la lecture, je ne sais pas.

Est-ce que les données peuvent être mis en cache, ou en partie? Cela peut influer sur la décision.

Personnellement, si tu dis que la base n'est pas conséquente, je partirais sur du tri dans le logiciel, le GC peut faire la gueule de temps à autre mais au moins tu respecteras très largement les 500 ms.

C'est difficile de répondre. Le plus simple est de faire le test !

SQLite est un "SGBD". A ce titre, ce genre de manipulation, il est fait pour.
En C#, tu peux le faire bien sur, mais tu risques d'augmenter la pression mémoire pour pas grand chose et déclencher le ramasse-miettes plus souvent.

Après, cela reste vraiment difficile de statuer s'en en savoir plus. Notamment, il ressort de ta description qu'il te faut plusieurs requêtes SQL, mais un seul tri de List. Est-ce bien le cas ? N'est-il pas possible d'avoir une seul requête SQL (par exemple, avec des UNION) ?

En fait, de manière automatisé à une fréquence allant de mini 500ms à plusieurs secondes suivant les demandes API - je nomme cela un cycle.

un cycle va potentiellement comprendre :
- Deux requêtes d'INSERT.
- Trois requêtes d'UPDATE/DELETE.
- Dix SELECT

En dehors de ce cycle, la manipulation de l'IHM entraîne plusieurs requêtes SELECT/UPDATE/DELETE/INSERT de manière peu fréquente...

Je pense que c'est tellement peu, que quelque soit l'approche que je décide, ça ne changera rien. Cependant, je souhaite appliquer une approche réfléchie.

Je retient qu'il est, à priori, préférable de multiplier les requêtes de lecture précise sur la BDD à la place de trier des List<>.

Merci pour vos retours.

Il y a aussi une chose éventuellement à gérer c'est les COMMIT- ROLLBACK
S'il y a une transaction toutes les 500ms et que l'une d'entre elles échouent alors c'est un truc à gérer.
Grosso modo je pense qu'une liste qui met en queue les transactions est appropriée.
Perso contrairement à la suggestion de François je ne suis pas trop partisan des grosses requêtes avec des UNION car le moteur du SGBD,je l'ai vu sur des projets d'entreprises, a tendance à pédaler