Optimisation un SELECT SQLite et/ou partager une base de données SQLite sur un serveur

Bonjour,

J'ai une base de données SQLite liée à une application C#. l'application peut créer des commandes SQLite à partir d'une interface ..
j'ai une rêquete de SELECT qui prend des millisecondes en local pour s'executer mais elle pourrait prendre une dizaine de minutes si le fichier .db est sur un disque partagé sur le réseau.

Voici un exemple :

Code:

---

1 2 3 4 5 6 7 8

SELECT [Sys_Central].[Id], [Sys_Central].[Demande_De_Travail],[DT_Demande_De_Travail].[Statut],[DT_Demande_De_Travail].[Descriptif],[DT_IPNs].[IPN_Demandeur],[DT_ObjectifsDT].[TypeDT],[DT_ObjectifsDT].[Jalon],[DT_ObjectifsDT].[DateJalon],[DT_ObjectifsDT].[DateFinSouhaite],[DT_Support_Projet].[Projet],[DT_Support_Projet].[Moteur],[DT_Support_Projet].[Boite],[DT_Support_Projet].[EngagementClient],[DT_Dates_Engagement].[Date_Engagement_MADC_DT],[DT_Dates_Engagement].[Date_Engagement_MADC_SE_DE],[DT_Date_Réalisé].[Date_Réalisé_MADC_DT],[DT_Date_Réalisé].[Date_Réalisé_MADC_SE_DE],[DT_Dates_Engagement].[Date_Engagement_Livraison_Fournisseur],[DT_Demande_De_Travail].[Satisfaction],[DT_Planning].[Remarque_Consultat],[DT_IPNs].[IPN_Consultant],[DT_Demande_De_Travail].[Remarque],[Id_DT_Demande_De_Travail],[Id_DT_IPNs],[Id_DT_ObjectifsDT],[Id_DT_Support_Projet],[Id_DT_Dates_Engagement],[Id_DT_Date_Réalisé],[Id_DT_Planning] FROM [Sys_Central] LEFT JOIN [DT_Demande_De_Travail] on [DT_Demande_De_Travail].[Id] = [Sys_Central].[Id_DT_Demande_De_Travail] LEFT JOIN [DT_IPNs] on [DT_IPNs].[Id] = [Sys_Central].[Id_DT_IPNs] LEFT JOIN [DT_ObjectifsDT] on [DT_ObjectifsDT].[Id] = [Sys_Central].[Id_DT_ObjectifsDT] LEFT JOIN [DT_Support_Projet] on [DT_Support_Projet].[Id] = [Sys_Central].[Id_DT_Support_Projet] LEFT JOIN [DT_Dates_Engagement] on [DT_Dates_Engagement].[Id] = [Sys_Central].[Id_DT_Dates_Engagement] LEFT JOIN [DT_Date_Réalisé] on [DT_Date_Réalisé].[Id] = [Sys_Central].[Id_DT_Date_Réalisé] LEFT JOIN [DT_Planning] on [DT_Planning].[Id] = [Sys_Central].[Id_DT_Planning]

---

je sais très bien que ce SELECT est énorme, 6 LEFT JOIN est difficile à optimiser mais la requête ne renvoi pas plus que 1000 lignes (le LEFT JOIN est essentiel) sachant qu'elle ne dure que quelques secondes maximum en local mais elle prend beaucoup plus de temps sur un serveur qui n'est pas très rapide ( et des fois c'est rapide sur le serveur ça dépend du réseau) .
Donc j'ai deux questions:
1 - est ce que c'est possible d'optimiser cette requête avec des indexations (sachant que les plupart des colonnes des jointure sont des clés primaires ça veut ils s'indexent automatiquement).
2 - comment puis-je partager une base de données SQLite sur un serveur Client-Serveur comme MySQL ou ORACLE .. pour que ça soit plus stable.

Je vous remercie pour votre temps.

Bonjour,

SQLITE est monoposte et pour autant que je sache surtout pas réseau. Lorsque tu fais une requête tu vas balader l'ensemble des données nécessaires à la requête sur le réseau (ce qui est différent d'un serveur qui lui ne transfère sur le réseau que la requête et les résultats. Comme le dit si bien le site SQLITE (https://www.sqlite.org/whentouse.html)

Citation:

---

A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network.

---

Donc :

1/ l'indexation ne changera pas grand chose (pour ne pas dire rien)

2/ Si tu veux absolument travailler sur un réseau, passe à un vrai serveur (MSSQL/Oracle/Progress...)

Cordialement

Je vous remercie pour votre réponse rapide ... pourriez-vous me recommander un bon outil pour migrer une base de taille moyenne de SQLite vers MySQL ou Oracle?.

Je vous remercie d'avance.

Il y a peut être des outils mais je ne les connais pas.

Personnellement, j'utiliserais la ligne de commande SQLITE3 et la commande dump comme indiqué ici https://www.sqlite.org/cli.html#conv...scii_text_file

Il suffit ensuite de modifier (si nécessaire) les ordres CREATE pour les rendre compatibles avec la base de donnée cible et d'y injecter le SQL.

Cdt

Citation:

---

Envoyé par acaumes

2/ Si tu veux absolument travailler sur un réseau, passe à un vrai serveur (MSSQL/Oracle/Progress...)

---

Citation:

---

Envoyé par WassING

Je vous remercie pour votre réponse rapide ... pourriez-vous me recommander un bon outil pour migrer une base de taille moyenne de SQLite vers MySQL ou Oracle?

---

Attention à ne pas confondre MSSQL (SQL Server) et MySQL
Comparez les caractéristiques de l'un et l'autre et vous verrez qu'il ne jouent pas du tout dans la même catégorie, même en version gratuite ;)
Quant à Oracle, attention au cout de la licence :weird:

Citation:

---

Envoyé par escartefigue

Attention à ne pas confondre MSSQL (SQL Server) et MySQL

---

Bonjour,

Ceci n'est pas le soucis ... mon client ne va pas probablement migrer de SQLite car la portabilité de la base est exigée.
Ce que je souhaite confirmer que le soucis ne vient pas de mon code (si une requête prend 0.5 seconde en local mais jusqu'à 30 minutes quand la base est sur le réseau) .
J'ai effectué des tests en partageant une base entre deux ordinateur et les résultats étaient moins catastrophique (0.5 secondes en local et maximum 5 secondes si la base est stockée sur un fichier partagé).

Avez vous des conseils pour mieux partager une base de données SQLite dans un réseau d'une centaines des utilisateurs (le partage j'ai effectué pour tester est limité pour 20 utilisateurs).
Je sais q'un nas peut résoudre le problème, cette solution est en cours mais je cherche une solution temporaire avant l'arrive du nas.

en vous remerciant pour votre temps.

Cordialement,

Bonjour,

SQLite n'est pas conçu pour le réseau, comme l'indique acaumes c'est clairement spécifié
Même si l'on peut envisager que SQLite soit multi-utilisateur il y a quand même quelques règles : une seule transaction en écriture.
Si vous tenez à rester SQLite il faut songer à une architecture multi-tiers en gros : un programme "serveur" sur le poste hébergeant la base qui fait le lien entre la base et les programmes clients

Citation:

---

Envoyé par WassING

Avez vous des conseils pour mieux partager une base de données SQLite dans un réseau d'une centaines des utilisateurs (le partage j'ai effectué pour tester est limité pour 20 utilisateurs).
Je sais q'un nas peut résoudre le problème, cette solution est en cours mais je cherche une solution temporaire avant l'arrive du nas.

---

Votre instance dans cette demande est imbécile et s'avérera catastrophique ! En effet SQLlite est conçu pour être exploité par un seul utilisateur et en accès direct (pas de réseau). En présence de plusieurs utilisateurs et de manière distante, les requêtes sont placées en série en file d'attente et augmenté des temps de disposition des données à véhiculer sur le réseau. Le temps de réponse que vous avez de 5 secondes sera donc, avec 100 utilisateur de 5 * 100 * LN(100) = 2303 secondes... En sus, compte tenue des méthodes de verrouillage de fichier véhiculés dans le réseaux, vos données peuvent être corrompues !
Je plains vos utilisateurs.

Pour info voici une copie de la doc de SQL Lite que vous trouverez en ligne :

***

Situations Where A Client/Server RDBMS May Work Better

Client/Server Applications

If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network.

***

TRADUCTION :

Situations où un SGBDR client / serveur peut mieux fonctionner

Applications client / serveur

Si de nombreux programmes clients envoient SQL à la même base de données sur un réseau, utilisez un moteur de base de données client / serveur au lieu de SQLite. SQLite fonctionnera sur un système de fichiers réseau, mais en raison de la latence associée à la plupart des systèmes de fichiers réseau, les performances ne seront pas optimales. De plus, la logique de verrouillage des fichiers est boguée dans de nombreuses implémentations de systèmes de fichiers réseau (à la fois sous Unix et Windows). Si le verrouillage des fichiers ne fonctionne pas correctement, deux clients ou plus peuvent essayer de modifier la même partie de la même base de données en même temps, ce qui entraîne une corruption. Comme ce problème résulte de bogues dans l'implémentation du système de fichiers sous-jacent, SQLite ne peut rien faire pour le prévenir.

Une bonne règle à suivre est d'éviter d'utiliser SQLite dans des situations où la même base de données sera accessible directement (sans serveur d'applications intermédiaire) et simultanément à partir de nombreux ordinateurs sur un réseau.

NOTA : en ce qui concerne l'aspect "boggué" dont SQL Lite parle, ceci est faux. Mais le verrouillage dans un réseau nécessite un service pour être contrôlé, ce qui revient à dire qu'on ne peut le faire hors d'une architecture client/serveur, ce que SQLLite n'est pas !

Citation:

---

Envoyé par SQLpro

Une bonne règle à suivre est d'éviter d'utiliser SQLite dans des situations où la même base de données sera accessible directement (sans serveur d'applications intermédiaire) et simultanément à partir de nombreux ordinateurs sur un réseau.

---

Je vous remercie pour votre réponse. Je vais donc proposer à mon client de migrer vers une base de données Client/Serveur.

Cordialement,