[C#]Avis choix base de données poste-local

Version imprimable

10/02/2015, 15h44
TANITE

[C#]Avis choix base de données poste-local

Bonjour,

Je viens vers vous pour avoir votre avis concernent le choix d'une base de données.
En fait je développe actuellement une application en C# avec des datagridview, des listView, treeview ....
Je pose la question concernant la base de données, j'ai remarqué que le chargement des data (20 lignes ) depuis un table d'une base access n'est pas instantané, j'utilise le driver oledb sous win7.

Avez-vous même comportement sous win 7 64 ?

Puis je commence a regarder la possibilité de faire une base sous forme des fichiers txt, .dat file
Que-pensez vous ?

Merci d'avance pour l'aide .
10/02/2015, 20h16
DotNetMatt

Citation:

Envoyé par TANITE

Puis je commence a regarder la possibilité de faire une base sous forme des fichiers txt, .dat file
Que-pensez vous ?

:mouarf: Libre à toi d'essayer, mais les résultats seront en plus désastreux ! Et ne parlons pas de la qualité (intégrité...) des données...

Citation:

Envoyé par TANITE

Je pose la question concernant la base de données, j'ai remarqué que le chargement des data (20 lignes ) depuis un table d'une base access n'est pas instantané, j'utilise le driver oledb sous win7.

Access n'est pas taillé pour des applications. C'un outil au même titre que Word ou Excel pour bidouiller dans son coin et se monter une petite moulinette sans trop d'effort et sans être développeur. En plus Access étant une base de données de type fichier, il souffre de nombreuses faiblesses.

Le mieux c'est de s'orienter vers un vrai SGBDR digne de ce nom, et en prime gratuit contrairement à Access, il s'agit de SQL Server Express.

Mais cela n'est pas non plus la solution miracle, encore faut-il savoir comment est-ce que tu as modélisé tes données. Une mauvaise modélisation donnera des performances désastreuses, quel que soit le SGBDR, le driver, etc. Et si tu as des problèmes de perfo avec Access sur une vingtaine de lignes, on peut très fortement soupconner un problème de ce côté...
10/02/2015, 20h43
StringBuilder

Pour 20 lignes, si le chargement n'est pas instantané, alors le problème ne vient pas de la façon dont les données sont stockées (Access, XML, TXT, SQL Server ou ce qu'on veut) mais avant tout un problème dans la méthode pour les charger.

En effet, je veux bien qu'Access soit pourri, mais il y a tout de même des limites.

Pour 20 lignes, on ne fera pas mieux que Access en termes de légèreté, mise à part peut-être un SQL Lite (et encore, pas sûr).

Que ça commence à merder avec quelques dizaines de milliers, et des jointures/filtres, OK. Mais un bête "select * from matable" qui contient 20 lignes, niet. Pas possible : si ça rame, c'est que vous avez oublié de nous indiquer des contraintes supplémentaires (base de donnés hébergée sur un serveur distant accessible via VPN en 2G, calculs mathématiques de cinglés sur les données chargées, données de type "blob" très volumineuses (images, documents) contenus dans ces 20 lignes, ou je ne sais quelle autre élément, du genre des boucles dans des boucles sur des événements qui déclenchent d'autres événements en mode "je fais n'importe quoi mais ça marche".

J'imagine notamment des jointures "à la main, en C# plutôt qu'en SQL", comme on en voit trop souvent.

Bref, donnez-nous plus d'informations sur :
- le contenu de la base de données actuelle
- les traitements que vous effectués lors de la restitution des lignes à l'écran
- si possible un bout de code pour qu'on se rende compte de la manière dont vous chargez vos données dans les datagrid par exemple.

Sinon, +1 avec la réponse précédente : SQL Server Express est une très bonne alternative à Access (on peut aussi avoir la version LocalDB, qui est plus légère). Mais à mon avis, votre problème de latence ne vient pas de là, et sera tout au mieux pire avec SQL Server (pour 20 lignes, aucune chance qu'un serveur qui bouffe 500 Mo de mémoire pour tourner puisse être plus performant qu'un drivers de quelques Ko, qui vont de toute façon bosser sur un fichier de données de même pas 1 Mo !

Salut,

Merci pour vos réponses !

Le code pas grand chose, c'est classique ....

Lors de l'init d'un user control :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 
 
        private void ucContacts_Load(object sender, EventArgs e)
        {
            try
            {
                // Chargement de la liste des contacts depuis la base de données
                //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                SetTelData();
            }
            catch(Exception myException)
            {
                MessageBox.Show(myException.Message,"Erreur",MessageBoxButtons.OK);
            }
 
        }

La methode SetTelData

Code:

1
2
3
4
5
6
7
8
9
10
11
 
        private void SetTelData()
        {
            DataSet ds = connclass.geDs("select ContactID,ContactFullName,GSMNumber,Description,Company,Address from ContactTable order by ContactID desc");
            dgvAllUser.DataSource = ds.Tables[0];
 
 
            // Mise a jour de la table pour pouvoir faire des recherche apres
            //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            ContactDataView.Table = ds.Tables[0];
        }

et au final couche d'acces à la base :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
        public DataSet geDs(string strSql)
        {
            OleDbConnection conn = DataConn();
            OleDbDataAdapter oda = new OleDbDataAdapter(strSql, conn);
            DataSet ds = new DataSet();
            oda.Fill(ds);
            return ds;
        }
 
        public static OleDbConnection DataConn()
        {
            string strg = Application.StartupPath.ToString();
            strg = strg.Substring(0, strg.LastIndexOf("\\"));
            strg = strg.Substring(0, strg.LastIndexOf("\\"));
            strg += @"\DataBase";
            strg += @"\user_db.mdb";
            return new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + strg);
        }

Merci d'avance

10/02/2015, 22h11
StringBuilder

Le code est pas hyper propre, mais rien de particulier en effet.

Dans la base, y'a quoi d'autre ? Quelle taille fait le fichier MDB ?

D'autres actions en parallèle ?

A quel moment on charge ce userControl ? C'est lent au premier chargement, ou tout le temps ?

Car tout accès à une base de données met du temps la première fois (chargement du drivers, chargement du fichier de données, démarrage du moteur de requête, etc.)

Mais là, clairement, ça devrait pas durer plus de quelques millisecondes pour charger les 20 lignes... (une fois le tout lancé, donc tester sur un rechargement du userControl).
10/02/2015, 22h34
TANITE

La taille de la base est de 964Ko.
Il y a d'autres tables, mais vide pour l'instant ....

pas de taches en parallèle, et je charge le user control uniquement une seule fois .
je vais tester le rechargement et vois si c'est mieux ...

Merci
11/02/2015, 11h19
Pol63

+1 pour le ca vient pas d'access
bien qu'un order by soit légèrement pénalisant (essaye sans pour voir s'il y a une différence)

après le dataset ca rajoute du temps

après il faut voir ce que tu appelles "pas instantané"
12/02/2015, 08h29
theMonz31

et pour répondre à ta question:

tu peux aussi utiliser SQL Server Compact Edition ==> C'est tout à fait adapter à de la gestion en local.. pas d'installation (contrairement à SQL Express)...
pas besoin d'avoir des droits administrateurs pour l'utiliser, bref... adapter pour faire une application portable :)
12/02/2015, 12h44
StringBuilder

Si je ne m'abuse, Microsoft ne fait plus évoluer SQL Server Compact Edition (qui n'a de SQL Server que le nom, puisque c'est moins complet qu'Access), et que ça n'a rien d'un SGBDR (surtout le R en fait).

En lieu et place, Microsoft recommande SQL Server LocalDB, qui nécessite qu'une installation allégée (tout comme SQL Server Compact Edition d'ailleurs, qui ne fonctionne pas "as this", il faut l'installer).
L'avantage de LocalDB, c'est qu'on a le VRAI moteur de SQL Server, et la majorité des fonctionnalités "standard" sont prises en charge (presque l'intégralité de la version Express), ce qui est un vrai plus par rapport aux autres solutions.
12/02/2015, 15h59
theMonz31

bah que SQL CE n'évolue plus, on s'en moque...

Ca fait le boulot.. associer avec un Entity framework, ça marche super bien...

Après, pourquoi pas faire du localDB...

moi, je dis simplement que le couple EF + SQLIte ou EF + SQL CE fonctionne parfaitement bien aujourd'hui.
12/02/2015, 16h26
StringBuilder

Je ne peux pas laisser dire que "SQL CE" ça marche bien.

Oui, ok, pour stocker 4 lignes dans 2 tables et ne faire aucun traitement dessus, ça peut suffire (et encore).

Mais si t'as des besoin un minimum plus complexes, et que tu code pas comme un ~~con~~ porc l'intelligence BDD dans l'application, mais côté base de données (contraintes, triggers, vues, procédures stockées, etc.) alors SQL CE ne supporte absolument rien de tout ça. C'est donc une solution soit pour faire un prototype de 4 lignes, soit pour faire de la 5 lettres. Mais qu'on ne me parle pas de "base de données" à ce moment.

Access est infiniment plus complet que SQL CE, donc quitte à choisir, autant utiliser Access, qui lui, ne demande effectivement pas la moindre installation.

Enfin, si on veut faire quelque chose de "propre", on peut se rabattre sur SQL Lite, qui reste selon moi un choix par défaut, ou LocalDB, qui est le seul choix qui s'impose de lui-même pour faire de la BDD locale.
12/02/2015, 18h06
theMonz31

moi je dis simplement que, parfois, les bases de données, on aime bien jouer avec autrement qu'avec du SQL.

Moi, les bases de données, ça me saoule.. alors si je peux faire "toute" l'intelligence ailleurs qu'en SQL, et ailleurs qu'avec des vues, et beh, c'est mon choix... et il
a le mérite de correspondre à mon besoin et de fonctionner parfaitement...

Après, on peut prendre SQLite... mais franchement, tous les besoins à BDD ne sont pas forcément consommateurs de View, triggers, proc stock, etc... parfois,
on veut juste stocker 3 infos et avoir quelques clés secondaires... rien de plus...

et en local, si c'est Linq ou EF qui fait le boulot de tri, j'suis pas sur qu'on perde énormément de temps avec les machines actuelles...

Ya pas de forcément de mauvais outils... faut juste prendre un outil adapté à son contexte...
12/02/2015, 20h50
Pol63

sql server ce je l'ai essayé, maitrisant sql server je me suis dit que ca serait bien
et j'ai été bien décu, et en effet même access doit être mieux, il manque des types, il manque des mots clés, des tas de fonctionnalités

après ca peut se comprendre que localDB ca soit un peu l'artillerie lourde dans certains cas, mais pour une appli pro ca ne pose pas de problème je pense
12/02/2015, 21h42
StringBuilder

Pour stocker "3 infos et quelques clés secondaires", il y a des méthodes à la fois plus adaptée et plus légères qu'une "base de données" (même SQL CE). Il y a le XML, les fichiers de config de type INI, la base de registre, etc.

Dès lors qu'on a "besoin" d'un outil de base de données (à savoir XML et autres consorts ne suffit plus), soit pour des raisons d'intégrité des données, soit pour des raisons de performances, alors une base fichier doit être systématiquement exclue, surtout quand cette base est aussi limitée que SQL CE.

On n'est pas dans le forum base de données, donc je ne vais pas m'étaler sur le sujet trois plombes. Mais utiliser des outils tels que EF, et autres NHybernate pour "s'affranchir du SQL", c'est avant tout s'exposer à de lourds problèmes :
- de performances
- d'intégrité des données
- de stabilité de l'application
- de complexité inutile du code métier

Aussi séduisant soit EF, mécaniquement, il fait du traitement séquentiel et itératif des données en mémoire. Par conséquent, dès qu'on lui demande un peu plus qu'une simple lecture séquentielle d'une simple table, ses performances sont catastrophiques par rapport à un SGBD, qui va traiter les données avec des algorithmes ensemblistes et parallélisés. Et on ne parle pas du gaspillage mémoire nécessaire pour faire une "jointure" avec EF par rapport à la même jointure proprement effectuée en SQL.
Alors effectivement, "avec les machines actuelles", on s'en moque un peu... Avoir besoin de 2 Go de mémoire pour afficher une liste des 30 DVD qu'on a sur son étagère, c'est peut-être pas choquant pour certains.

Il y a pourtant des outils adaptés pour chaque chose. Quand tu jardines, tu creuse pas des trous avec un fourchette. En informatique, tu utilises pas un langage itératif pour travailler avec des données. C'est la même chose.
13/02/2015, 12h22
Pol63

(des sources d'il y a 5 ans)

enfin moi la prochaine fois que je fais une petite appli j'essaye sqlite, sql server ce je n'y vois aucun intérêt
de plus sqlite c'est une dll de moins d'1Mo à copier, pas un exe de plusieurs dizaines de Mo à installer