Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Embarquer une base de données MySQL
Bonjour,
voilà, j'ai mon application qui utilise une base MySQL,
j'ai un serveur d'installé en local, mais j'aimerai bien pouvoir utiliser
ma base de données à la manière d'Access, sans forcément installer un serveur sur le client (application lourde).
Comment ferriez vous?
Un autre système qu'une base de données MySQL?
En fichier uniquement, il existe Access, SQLite mais ils sont moins performant que MySQL sur le long terme.
Oui, forcément... MySQL ne fonctionne pas sans installer de serveurEnvoyé par dtcSearch
Access n'est pas terrible, mais SQLite a des performances très correctes, même pour des bases assez grosses (peut-être pas pour des Go de données, mais pour quelques dizaines ou centaines de Mo ça marche bien). En plus, le provider ADO.NET pour SQLite supporte Entity Framework
Sinon, tu peux aussi jeter un coup d'oeil à SQL Server Compact Edition, qui a l'avantage de bien s'intégrer avec Visual Studio et .NET
Merci pour votre réponse,
je cherchais encore et je suis tombé là dessus:
http://stackoverflow.com/questions/4...ives-to-sqlite
Il en ressort une liste assez sympa:
VistaDB
DotNetFirebird
SQLCE (un teste entre SQLCE et SQLite)
SQLite
H2 Database Engine (plutôt Java, pas utilisable en DotNet, enfin j'ai rien trouvé)
Et ici:
http://www.connectionstrings.com/
Y'a une grosse partie sur les "Data Files"
Excel 2007
Excel
Textfile
Access 2007
Access
Visual FoxPro / FoxPro 2.x
DBF / FoxPro
SQLite
Filemaker
Bref, je pense que SQLite est sans doute le meilleurs choix dans un mode Stand Alone.
Juste une dernière question, imaginons que nous faisions un Installer qui inclurai MySQL.
Si un autre programme lancer en même temps utilisant MySQL, ça bloquerai notre programme (en toute logique), il faut prévoir ce cas, faire une configuration particulière de MySQL (changer de port suffit?)
Sql Server Ce (version actuelle 3.5 SP2) présente l'avantage en développement .Net de pouvoir utiliser Linq .Net et Entity (en plus, mais cekla ne concerne que les utilisateurs Sql Server, de la réplication de fusion avec 2005 et 2008).
C'est un avantage effectivement.
J'aimerai savoir niveau performance, lesquels sont les mieux?
Mon cas est le suivant, une grosse base de données avec assez peu d'accès concurrent (peu de charge) (< 2 requêtes / secondes)
Je vous remercie d'avance
En performances pures, SqLite *semble* (pas fait d'essais comparatif car je ne les utilise pas du tout pour le même usage) plus rapide, sous réserve de toujours utiliser les transactions en écriture (sinon c'est une cata ....)
Cela ne compense pas à mon avis tous les autres inconvénients et notamment son absence totale de sécurité (pas de contraintes d'intégrité, etc ....)
Bref, SqLite, pourquoi pas mais, pour ma part, pas pour des données métiers persistentes. En revanche, en tant que SGBD embedded pour des traitements pourquoi pas.
Autre avantage de Sql Ce, c'est qu'on peut manipuler la base avec SSDE (mais encore une fois, cet avantage doit être relativiser pour un non utilisateur de Sql Server 'Server').
Qu'entends tu par "grosse" base ? et tu l'embarques sur quoi ? (Tablet PC, PC portable ?).Mon cas est le suivant, une grosse base de données avec assez peu d'accès concurrent (peu de charge) (< 2 requêtes / secondes)
Je vous remercie d'avance
Il y a une librairie libmysqld.dll qui théoriquement permet de faire un serveur embarqué, mais je n'ai jamais pu l'utiliser avec c#.Oui, forcément... MySQL ne fonctionne pas sans installer de serveur
Il y a de la doc à ce sujet sur le net....
Par grosse base, j'entends une base qui va contenir 10 ans de métier à raison d'une 100ène de nouveaux enregistrements par jours, qui peut au final frôler les 2Go je pense (en fonction de la base bien sûr).
En faite, le projet est assez simple, c'est une appli métier, mais je ne voulais pas installer une SGBG sur la machine parce qu'elle peut être connecté à un serveur mais aussi travailler en "déco" donc dans une petite base qui sera synchronisé par la suite.
Pour moi, l'emebeded était une solution simple qui permettait un compromis.
Maintenant, vu qu'il est possible d'utiliser MySQL en embeded, là, ça devient assez intéressant, parce que ça permettrait de faire les deux cas de la même façon.
Sinon, pour mon cas? un SGDB? ça serait mieux peu être non?
(MySQL Embeded for C# avec libmySQL.dll > http://www.cybercom.net/~zbrad/DotNet/MySql/)
Ok. Le concept de "grosse base" rentrant dans le cadre des UPP (Unités Pifométriques Personnelles) il est en effet plus simple de le préciser.
J'avoue ne pas voir dans ton cas d'avantage (au contraire) à ne pas installer un serveur sur la machine. Du point de vue de la syncho c'est même un inconvénient.En faite, le projet est assez simple, c'est une appli métier, mais je ne voulais pas installer une SGBG sur la machine parce qu'elle peut être connecté à un serveur mais aussi travailler en "déco" donc dans une petite base qui sera synchronisé par la suite.
Pour moi, l'emebeded était une solution simple qui permettait un compromis.
Si y'a déjà un serveur d'installer dessus?
:S c'est ça qui m'embête, le fait d'installer un service sur la machine (tierce) qui peut entrer en conflit avec une autre application.
ps: pour ce qui est de la taille de la base de données, pour être plus précis, je dirais une palanqué de données.
Finalement, je pense (pour des questions de licences) que PostgreSQL est la meilleurs solutions dans mon cas. Je garde la notion de SGDB et de service.
Merci pour votre aide
SQLite aussi
Au temps pour moi alors; il est vrai que je n'ai pas travaillé avec SQLite depuis près de deux ans.SQLite aussi
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager