Bonjour,
Je débute avec un projet en vb.net qui programme le port série afin de récupérer des données via des mobiles.
J'ai besoin de stocker ces données,vous me conseillez d'utiliser Access 2010 ou sql serveur au niveau de fiabilité?
merci
Version imprimable
Bonjour,
Je débute avec un projet en vb.net qui programme le port série afin de récupérer des données via des mobiles.
J'ai besoin de stocker ces données,vous me conseillez d'utiliser Access 2010 ou sql serveur au niveau de fiabilité?
merci
sql server
plus fiable, plus rapide, permet de faire plus de choses etc...
Merci pour la réponse rapide.
J'ai deux autres questions:
1- Est-ce que je peux utiliser l'édition Express de sql server avec la version visual studio complète sans problème?
2-Au niveau de déploiement, j'aimerai à la fin de mon programme avoir un seul fichier .exe,est ce que j'aurai besoin de sql serveur sur les machines sur lesquelles je vais utiliser mon program.exe?
Merci beaucoup
l'édition express fonctionne avec toutes les éditions de vs
il a des plus de limites que les versions payantes (base de 10Go à partir de 2008 r2, utilsiation d'un proc et d'1Go de ram seulement etc...)
sql server est un base de données réseau, on accède pas à la base de données en ouvrant un fichier comme avec access, c'est un programme à installer qui peut lire les données, le programme se connecte à sql server (par tcp/ip par exemple)
si vous voulez une base de données fichier mono utilisateur ne nécessitant pas grand chose à l'install utilisez sql server CE (gratuit aussi)
Merci beaucoup, je reviendrai vers vous une fois je suis dedans s'il y a un problème:ccool:
SQLite est aussi intéressant comme DB légère monopost
Gratuit tout à fait
SQLite serait plutôt un peu du genre d'Access (sans la possibilité de créer des rapports, etc donc uniquement un schéma DB et les données). La base de données est sous la forme d'un seul fichier, donc que vous pouvez placé dans le répertoire de l'exécutable de l'application. Donc sur chaque poste.
Donc pour l'utiliser vous devez installer un provider (l'équivalent du client de SqlServeur mais pour SQLite) : faite une recherche par exemple sur
sqlite-netFx35-setup-bundle-x86-2008-1.0.77.0 qui est l'installation de celui-ci (je pense que maintenant il y a une nouvelle version).
Pour créer votre fichier correspondant à votre DB vous pouvez utiliser SQLite Expert Personal qui est très simple d'utilisation est très performant. Il permet de créer de nouvelles bases de données, les tables, vues , etc etc.
Il est bien sur possible de créer la DB par programmation. Je dois travailler sur un tutoriel pour l'utilisation de SQLite mais je n'ai pas encore eu le temps de m'y mettre.
En faisant une recherche de SQLite sur google vous tomberez sur le site avec plus d'information.
Je reste à votre disposition si vous avez d'autres questions
Merci bien infosam76, c tout à fait intéressant comme un sgbd je vais me renseigner plus sur les détails de mise en relation avec vb.net,et je vous solliciterai si besoin:ccool:
ca reste quand même moins bien qu'sql server CE qui est aussi une base fichier, sauf qu'il y a tout ce qu'il faut dans le framework nativement pour s'y connecter
et on peut même créer sa base de données dans visual studio
Si tu veux utiliser une base "in process" tu peux aussi dans ce cas prendre Sql Server CE (CE pour Compact Edition), qui a le mérite de s'intégrer à la fois dans VS et dans SSMS.
Avantage : si tu changes d'avis, le passage à une version "server" (Sql Server "normal" ou Express) de l'application est plus simple que avec SqLite (syntaxes Sql plus proches l'une de l'autre).
La question que tu dois te poser pour le choix "in process" ou "serveur" est de savoir si ton application est susceptible d'être utilisée sur plusieurs stations avec une consolidation commune des données ou pas. Si oui, la choix d'un SGBD est nettement préférable, dans le cas contraire une base "in process" peut convenir (SqlIte ou Sql Server CE).
Je te déconseille Access qui est un peu une cotte mal taillée entre les deux options,
qui présente par ailleurs des avantages en tant qu'outil "end user" pour un non informaticien mais qui en présente peu en tant que composant de persistance pour une application à développer.
Dans cette dernière optique, le choix de Access peut néanmoins se justifier, si, et seulement si, on considére que les utilisateurs finaux vont être amenés à faire leurs propres "query" eux même.
Merci Bluedeep et Pol63 pour vos réponses,
En fait j'ai besoin juste d'une base de données à inclure avec mon programme vb.net pour stocker et consulter les données,et j'aurai besoin de l'avoir à chaque fois sur la machine où j'installe mon programme,donc à priori pas de multi-user.
D'après vos réponses, il me semble que SQL server CE et la meilleure solution pour mon cas(à confirmer)
Merci Beaucoup:ccool:
Effectivement évité ACCESS car pour l'avoir utilisé pendant des années il présente à mon sens de gros soucis d'instabilité au dessus de 100-150 mb de data. Et on peut y arriver très vite.Citation:
Je te déconseille Access qui est un peu une cotte mal taillée entre les deux options,
qui présente par ailleurs des avantages en tant qu'outil "end user" pour un non informaticien mais qui en présente peu en tant que composant de persistance pour une application à développer.
Bonjour
Pourquoi éviter Access ?
Tu peux l'utliser sans avoir Access sur ton poste, tu peux même la créer par programmation dans ton application, donc pas d'install de ce coté.
Quand à l'instabilité, c'est souvent un problème de conception, je l'utilise tous les jours depuis des années et sans soucis.
Philippe
ca je veux bien y croire, par contre conseiller access non
un outil doit être pratique, ce n'est pas le cas d'access
les messages d'erreurs qu'il délivre sont très spartiates "votre requete ne va pas", un vrai sgbdr vous dit où dans la requete vous avez écrit une connerie
il y a aussi de gros pièges avec access, lors de l'utilisation de DbParameter depuis ado.net il ne regarde pas le nom des paramètres mais les prend dans l'ordre d'instanciation, donc en cas de modification de requete ca peut bugger sans qu'on sache pourquoi
access ne libère pas d'espace en cas de delete (=> compacter la base de données)
et il y a plein d'autres raisons de ne pas utiliser access
Bonjour
Il y deux manières de voir Access : soit comme outil de gestion de données end-user, soit comme SGBD pour une application.
Autant je peux comprendre le choix de Access dans le premier cas, autant je ne vois pas d'arguments valables justifiant son choix comme SGBD pour une application actuellement.
Bonjour,
Moi aussi je suis d'accord qu'Access en tant que SGBD ce n'est pas top, j'ai rencontré pas mal de problèmes et messages d'erreurs aussi.
Actuellement j'ai installé Visual studio Express 2010( en attendant l'arrivée de la licence pour Visual studio).et sql serveur Express 2008 était inclut dans le pack.donc je vais commencer par ça et après je bascule sur la version CE.
Access fonctionnait pas mal jusqu'à avoir dépassé une certaine taille donc quantité de données. Il a des avantages mais tant qu'on reste avec des bases de données de taille réduite. Maintenant je précise qu'il s'agissait d'Access 2007 cela a peut-être changé depuis.
Re
Je respecte le choix et les opinions de tous, ainsi que leur expérience.
Professionnellement j'utilise Access tous les jours, une partie de mon métier consiste à gérer des fichiers d'adresses, et des programmes spécifiques.
Je gère environ une centaine de bases différentes et jusqu'à 1.5 Go, soit en direct (tout dans Access), soit pour stocker les données (Interface en VB6 et bientôt en VB.net).
Et donc je parle de mon expérience personnelle qui est positive dans ce domaine.
Mais tous les avis sont les bienvenus.
Mon message était pour aborder une solution possible, pas d'installation, on embarque la base mdb avec le setup, et pas besoin d'avoir Access sur le poste.
Philippe
Cet argument ne peut pas être lié à une base de données sans exemples, sur sql server avec un bi octocore tu peux avoir des performances très dégradées même avec moins d'un 1Go de données dans la base
ca dépend du schéma de la base et de l'écriture des requetes, donc de la connaissance du sgbdr