Discussion :

[lilloDay]

Bonjour,

Je développe mon application avec C# et un accès sur une BD, j'ai choisis access puisque c'est ce que je connais le mieux. En plus je commence à apprendre C#.

Hier j'ai eu une discussion avec 2 autres personnes et ils m'ont dit que Access relenti beaucoup le processus et que MySQL est beaucoup moins lourd

Ma ou mes question(s) est (sont)

1. Qu'est ce qui a influencé votre choix de BD
2. Est ce que c'est vrais que Access ralenti le processus d'accès aux données
3. Est ce que c'est facile de developper avec My SQL
4. Pour ceux qui utilisent MySQL : comment ca fonctionne avec C# et je pourrais trouver des informations, et le plus important comment je peux déployer sur la station de l'usager
   

Beaucoup de questions j'espère trouver certaines réponses

P.S : je ne sais pas si c'est la bonne section pour poser ma question !!!!

Merci

[sinople]

Le problème avec Access (base de donnée Jet en réalité) c'est que les performances ont tendance à se dégrader très rapidement avec le nombre de connexion simultannée (même si c'est environ 250 connexion officiellement), en effet à 3 connexion on a déjà 50% de pertes.

Sachant qu'avec ADO.net on travaille en mode déconnecté en principe ca ne devrait pas trop déranger si on est encore dans l'ordre de la dizaine d'utilisateur (bien entendu ça dépend du code...). A noter aussi une limite de la taille de la base à quelques giga (4go de mémoire à vérifier)

Néanmoins c'est une piste en cas de ralentissement sevère!

L'avantage c'est que c'est facilement administrable, pas trop chère et tourne relativement bien avec .Net (on reste dans du microsoft).

Autrement je conseillerai plutot du SQL Server que MySql car SQL Server est implémenter en natif avec ado.net, ce qui est pas le cas MySql.

A Savoir qu'il y a des versions de SQL Server gratos (les version express), que ce n'est pas trop compliqué à administrer si on rentre pas dans les détails, mais que ces dernières ont des limitations de performance (5 connexions simultanée max, 1 processeur utilisé, 1 Go de ram utilisé max, 4 Go pour la base, à vérifier aussi). Mais l'upgrade est réalisable en cas de besoins de perf contrairement à Access (Ou la faut soit changer de BD, soit optimiser son code si ca sature...)

[lilloDay]

Merci pour la réponse

Il va y avoir une seule connexion à la fois à la BD Access. la taille je ne crois pas que je dépasserais le 1GO, depuis 7 ans d'ajout dans la BD la taille est pas plus que 60MB, alors je crois que c'est correct !!!!

J'ai déjà pensé à SQL express, mais ce qui me fait peur c'est le deploiement sur la station de l'usager ..

Merci encore

[meziantou]

J'ai déjà pensé à SQL express, mais ce qui me fait peur c'est le deploiement sur la station de l'usager ..

Autrement il y a sql compact edition.

[lilloDay]

Autrement il y a sql compact edition.

Est ce qu'au niveau de la programmation et la connexion à la BD reste la même qu'avec Access et compagnie ???

J'ai oublié de dire que je travaille avec VS 2010

Merci

[cinemania]

le déploiement d'un sql express quelque soit le poste reste du domaine du très simple...

on te demande pas non plus de déployer une SQL SERVER 2008 R2 ENTERPRISE EDITION ou DEVELOPER EDITION (encore plus chiante et complète)

comparativement, l'installation de sql server 2008 express prend en moyenne 5mn quand les prérequis sont observés, 10 sans... et quasiment aucun truc à configurer si ce n'est le mode d'exposition du serveur et le type de connexion et savoir si toute session de la machine est toujours automatiquement reconnue comme Server Admin.
bon si tu es sous Seven x64, il faut également installer le SP1 de SQL 2008 si tu as installé les advanced tools...
en effet tu as 2 types de SQL Server Express... une version normale à déployée avec un produit fini chez un client, et une version pour développer avec des advanced tools...
là l'installe est plus longue, mais tu as Management Studio d'installé sur la machine, qui est un environnement graphique COMPLET qui permet d'administrer totalement ta base de données, de fond en comble.

si on veut continuer le comparatif, il faut en moyenne 40mn d'installation quand tous les prérequis sont observés pour une SQL SERVER 2008 R2 DEVELOPER EDITION, et ca sans parler du temps que tu passe à confirmer, à choisir, ce que tu veux, vérifier les rapports ... configurer les droits de chaque service ....
on est clairement pas dans le même produit.

Pour information, les restrictions de SQL Server 2008 R2 Express (en anglais uniquement l'instant) sont 10Go de données par base, une seule instance EXPRESS par machine, et comme d'habitude limitation à 1 processeur (mais chez Microsoft, 1 processeur c'est 1 processeur, c'est pas comme Oracle qui appel 1 processeur 1 simple core qu'il soit logique ou physique, vive les core i7 et l'hyperthreading...)
Pourquoi passer à SQL Server plutôt qu'ACCESS ?

bien même si tu peux travailler sur un fichier SQL Server directement plutot que sur le moteur lui même, SQL Server meme express gère parfaitement les transactions et l"intégrité relationnelle, de façon plus nette que ACCESS qui autorise des raccourcis disons le dangereux, et nuisent à l'assurance de la cohérence des données.

Maintenant il est vrai que SQL Server meme en version Express c'est peut être un peu comme chasser le moustique au canon... mais bon, l'intégration native de SQL Server à DOTNET risque nettement d'améliorer la donne surtout si tu travail avec des technologies comme Entity Framework.

Pour tes questions relatives à MySQL, on peut tout à fait utiliser MySQL sous Dotnet et sous windows, mais bon... c'est loin d'être le couple le plus heureux, et même avec les connecteurs fournis par MySQL pour dotnet, les performances sont quand même loin d'être au rendez vous, même si c'est toujours mieux que d'utiliser les ODBC ou le support OleDB.
Le connecteur MySQL est en téléchargement libre sur le site de MySQL (pour combien de temps encore ? vu que des trucs disparaissent un peu plus chaque semaine de ce site... vive Oracle)
Ou sinon tu dispose d'un connecteur optionnel pour VS2010 développé par Devart, qui supporte tout comme le connecteur du constructeur les providers et un support des dernières techno microsoft ADO.NET Entity Framework.
Mais il est payant à l'inverse du connecteur d'origine. (une version free hyper light existe)

Globalement la base MySQL sera moins pertinante sous dotnet qu'une base SQL Express, surtout qu'il est fort à parier que les volumétrie sont de même grandeur.
Typiquement MySQL est une base qui sera utilisé pour tout ce qui est consultatif uniquement, car cette base ne propose pas de mécanisme d'intégrité relationnelle et donc aucun mécanisme de contrôle d'intégrité des données. Quand à la gestion des transactions elle n'est possible que si tu as développé tes tables avec le moteur InnoDB ce qui fait chuter dramatiquement les performance...

Donc le choix du modèle de DB dépend entièrement de ce que l'on en fait et de la technologie avec laquelle on le fait.
Si ton appli est dispatchée sur plusieurs tables et que tu fait beaucoup de recoupements entre les tables et autre, évite à tout prix ACCESS et MySQL.
Si en revanche tu travail sur des tables plannaires qui contiennent toutes les données dont tu as besoin en 1 seule fois sans jointures ou quoi que ce soit, MySQL est ton ami, mais surtout pour du consultatif.

Il faut aussi noter que même si Microsoft a mis un point d'honneur à développer son moteur de base de données SQL Server autour des jointures dites "forcées" avec JOIN, et ce quelque soit le type de jointure, et pour lesquelles on obtient de meilleures performances qu'avec une jointure naturelle de type SELECT * FROM table_1 t1, table_2 t2 WHERE ...
Ce n'est pas le cas des autres SGBD... pour lesquelles les performances sont dramatiquement plus faible avec des jointures déclarées avec JOIN, contrairement aux jointures naturelles, comme par exemple sous MySQL.
Hors il faut retenir que la première chose qu'on t'apprend à faire quand tu apprend à requêter une base de données, et ce quelque soit le support, c'est d'y aller à la sauvage avec des
SELECT * FROM table1 a JOIN table2 b ON a.ID = b.A_ID WHERE ...
Il est clair que cette écriture est plus simple à lire car la jointure tape à l'oeil et on a plus dans le where finalement que les conditions discriminantes, mais voilà... c'est un état de fait à ne pas négliger.

Comme déjà dit l'intégration de SQL Server ou de SQL Compact Edition est plus naturelle quand tu travail avec VS2008 ou 2010, mais il faut faire très attention à ce qui est supporté et pas supporté sur la Compact Edition qui n'évolue plus.
Si mes souvenirs sont bons le connecteur natif SQL Compact Edition ne fournit pas tous les providers nécessaires au fonctionnement de Entity Framework et donc de Linq to Entities, par exemple, mais là je ne suis plus sure vu que je travail toujours soit avec des versions Express de SQL Server pour les appli en production, soit avec des versions DEVELOPPER EDITION dans le cadre du développement.

En fait, il est préférable sous VS2010 d'oublier tout cours ACCESS et donc ODBC, JET, OLEDB. Il faut aussi savoir que VS2010 ne fournit plus les connecteurs natifs JET nécessaires pour travailler avec une base en fichier ACCESS, ce qui signifie que si tu n'a pas ACCESS sur le poste où est VS2010... tu ne peux pas travailler avec le fichier sauf via les ODBC... mais alors là, c'est carrément la bérézina en terme de performances.

Pour toi, tu inclu le namespace

Code :

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

1
2
3
4
5
6
7
8
 
using System.Data.SqlClient;
 
SqlConnection doConnect(string connectionString) {
  SqlConnection sql = new SqlConnection(connectionString);
 
  return sql;
}

tu va ensuite travailler sur des objets Sqlxxxx au lieu de Dbxxxx ou que sais je encore.

Tu peux aussi utiliser ADO.NET ENTITY MODEL et générer ton modèle objet Entity Framework depuis ton modèle de données déjà existant... là tu choisi une chaine de connexion, la base, le provider ... tu choisi le domaine de données à modéliser, et zou il te pond un schéma visuel objet qui est le reflet de ta base de données.
Ensuite au lieu de tapper des requêtes toi même sur SQL tu utiliser Linq To Entities genre

Code :

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

1
2
3
4
5
6
7
 
Customer getCustomer(int id) {
  using (CustomersEntities entities = new CustomersEntities())
  {
    return (select n in entities.Customers where n.id=id select n).FirstOrDefault();
  }
}

(faut juste pas oublier en plus le namespace System.Linq)

[meziantou]

Est ce qu'au niveau de la programmation et la connexion à la BD reste la même qu'avec Access et compagnie ???

Ca reste identique a SQL Server. Donc c'est parfaitement compatible avec des technologies comme Entity Frammework.

[sinople]

Il y a quand même certains truc qui change entre la connexion access et sql serveur (et pas uniquement la chaîne de connexion...)

C'est pas du domaine de l'impossible mais faut compter plus que 5 minutes

[ClaudeBg]

Pour ceux qui utilisent MySQL : comment ca fonctionne avec C# et je pourrais trouver des informations, et le plus important comment je peux déployer sur la station de l'usager

Moi, quand j'ai une BDD utilisant une seule connexion, j'utilise SQLite .Net.

Ca fonctionne super-bien et c'est très bien adapté à une Bdd locale.

Il suffit de télécharger le pack ici http://sqlite.phxsoftware.com/

Une fois installé c'est directement utilisable dans VS et ça permet l'utilisation de linq.

A l'intérieur du pack il y a en réalité la librairie open-source SQLite englobée dans un environnement donet. Ca consomme très peu de ressources tout en restant très flexible.

Seul bémol pour l'instant, ce n'est pas encore porté sur Framework 4.0, ça ne fonctionne que pour les projets jusque 3.5.

Sur le site tu as même une vidéo de démonstration.

A+
Claude

[Hinault Romaric]

Sachant qu'avec ADO.net on travaille en mode déconnecté en principe ca ne devrait pas trop déranger si on est encore dans l'ordre de la dizaine d'utilisateur (bien entendu ça dépend du code...). A noter aussi une limite de la taille de la base à quelques giga (4go de mémoire à vérifier)

DataSet = mode déconnecté
DataReader = mode connecté
DataSet et DataReader objets ADO.net

@++

[sinople]

DataSet = mode déconnecté
DataReader = mode connecté
DataSet et DataReader objets ADO.net

Encore heureux que y a un objet pour se connecter à la base, autrement je vois mal comment on récupère les données!

Datareader ne fonctionnant que en lecture seul, et en avant seulement. Du coup son utilité principale est de charger les données en local (dans un dataset au bol, ou autre tableau, liste, vache et cochon) pour traitement ultérieur.

Ca limite quand même pas mal le squattage de connexion avec la base.

Bien entendu en fonction du code....

[cinemania]

sinople c'est un peu plus compliqué que cela...

pour accéder aux bases de données, on dispose de deux choix possibles...
un mode connecté, qui suppose qu'à chaque fois que tu accède à une donnée, en réalité tu la demande directement à SQL, même ne serait qu'une colonne d'un enregistrement, et ce tout le long de ton application.

le mode déconnecté proposé par ADO.NET est de lancer une connexion si ce n'est déjà fait, lancer la requête et récupérer l'intégralité du résultat en mémoire, clore la requête (pas forcément la connexion), et de réorganiser les données reçues pour que tu puisse les exploiter.

Le datareader conserve la requête ouverte pendant toute la durée de son exploration, donc il n'y a pas de données en mémoire coté dotnet, sauf le tuple en cours de lecture, à chaque avance sur le datareader, il reçoit le tuple suivant depuis la base de données.
c'est le mode connecté, exclusivement utilisé auparavant, et c'est d'ailleurs le mode utilisé pour travailler avec mysql sous PHP3-4/5 la plupart du temps quand tu utilise les commandes mysql_xxxxxx.
(pour les objets DB de php5 je ne me prononcerais pas, ca dépend de leur implantations respectives...)

un dataset est rempli à l'aide d'un datareader qui n'est d'ailleurs conservé que pendant la durée exacte de remplissage du dataset, puis clos et détruit juste après, ce qui ferme la requête, et tu peux alors travailler sur les données, de façon déconnectée, puisque la requête est libérée quand tu manipule l'ensemble des données qu'elle a retournée.

on vois clairement là, la différence de principe, et de contexte, voila ce qui signifie connecté/déconnecté...
cela ne signifie pas comme tu pense le croire qu'on récupère les informations par l"'opération du saint esprit sans jamais ce connecter à la base de données.
de plus, il n'était pas obligatoire de fournir les DataReader qui fonctionnent en mode connecté, puisque toute la force de ADO.NET est justement de travaillé en déconnecté.
Encore une fois ils ne sont là que pour travailler sur des requêtes retournant des quantités pharaoniques de données, permettant ainsi de fenêtrer la requête... généralement un développeur n'a pas besoin d'utiliser le DataReader lui même.

[sinople]

Euh...

Tu me retrouves le passage ou je dis que c'est l'objet saint-esprit qui charge un dataset?

Par contre je suis curieux de savoir comment tu utilises les données d'un datareader dans ton programme sans les mettre en mémoire dans ton application (et du coup être déconnecté!)?

Et aussi comment charger un dataset de 1 table avec 1 enregistrement depuis ta base de donnée sans utiliser un datareader !

Pour ceux qui veulent comprendre la différence entre les mode connecté/déconnecté je recommande plutôt d'étudier les principes de fonctionnement de ''feu'' DAO et ADO.Net