Discussion :

[gadsweb]

Bonjour à tous,

Alors voilà j'ai une interrogation sur une appli que je vais démarrer.
Je sais utiliser C# avec une base de données Sql Server ou autre, çà c'est pas le soucis.
Ce que j'aimerais cette fois-ci c'est utiliser avec une base locale, car je ne pourrai pas installer de serveur sur la machine qui va héberger l'appli.
Donc, est-ce possible d'utiliser une base locale sous forme de fichier par exemple, sans sql server ou express ou sqlite ou autre (bref, sans serveur :-)) et la cerise serait que ce soit multi-utilisateurs simultanés ?
Bien évidemment, si oui, comment ?
Merci d'avance

[theMonz31]

Bonjour

SQLite ne demande pas de serveur...

Sinon, SQL Compact Edition (mais certains ici n'aiment pas du tout)...

sinon, avec la dernière version de VS 2012 (ou 2013, je ne sais plus), il y a la possibilité d'ajouter une base locale (sans SQL Server ou autre).

Pour le multi-utilisateurs, à toi de gérer la concurrence (comme pour SQL Server).

[Pol63]

le choix dépend de ta base
si elle doit faire 500Mo et mono utilisateur, alors oui une base fichier irait
si c'est pour du multi user, il faut une base réseau, certaines bases fichiers peuvent s'utiliser en partageant un dossier (comme access)
sqlite est censé être bien, je ne sais pas s'il faut multi accès par contre

après sql server (le vrai) ne nécessite pas forcément d'avoir un serveur physique, tu peux l'installer sur un poste client et dire de ne pas éteindre le pc car il sert de serveur pour les autres

donc il faudrait détailler un peu (taille, nb tables, utilisation locale ou réseau, nb requetes minutes, etc...)

[gadsweb]

Merci pour vos conseils.
Pour être un peu plus précis : une 15aine de tables, 100Mo Max, à la louche 200 requêtes/h, multi-user impératif
En fait l'accès à l'appli se fera via RDP.
J'aurais donc voulu un .exe avec un fichier comme base, car c'est un peu compliqué à expliquer, mais j'aimerais éviter l'installation d'un quelconque SGBD et c'est là que je ne sais pas si c'est possible.
Si je ne trouve pas de solution assez souple et sans trop de contraintes, ben tant pis, j'en ferai mon deuil et passerai comme d'hab sur Sql Server.

[theMonz31]

d'un autre coté, vu que le multi-user est impératif, il me semble raisonnable de mettre un SQL Server en face pour couvrir les besoins...

[Pol63]

les 3/4 des bases de données fichiers ne requiert qu'une dll (à côté de l'exe par exemple)
c'est le cas d'sqlite
concernant access, msjet est en général fournit avec windows (dll x86 permettant d'accéder à une base access) ; en x64 il faut installer ace ole db

d'après un post sur sqlite de 2011 (à vérifier aujourd'hui car tout évolu) il verrouillerait toute la base pendant un accès, ce qui ne serait pas forcément génial pour du multi user, à ma connaissance access n'a pas se comportement

[François M.]

Bonjour

SQLite ne demande pas de serveur...

Sinon, SQL Compact Edition (mais certains ici n'aiment pas du tout)...

C'était pourtant un bon composant mais il est "deprecated" maintenant.

SQL Server compact edition is in deprecation mode with no new releases planned near future

[François M.]

Bonjour

Je sais utiliser C# avec une base de données Sql Server ou autre, çà c'est pas le soucis.
Ce que j'aimerais cette fois-ci c'est utiliser avec une base locale, car je ne pourrai pas installer de serveur sur la machine qui va héberger l'appli.

La solution évitant l'installation est d'utiliser LocalDb. (c'est un serveur mais local à l'application, contrairement à Sql Server CE qui est une base "in process").

http://blogs.msdn.com/b/sqlexpress/a...l-express.aspx

Mais de quel type d'applicaition s'agit-il ? une application "client lourd" en multi-utilisateurs ? Dans ce cas, je ne vois pas d'autres solution que Sql Server Express (a minima).

Bref, il faudrait plus d'infos.

[pascalCH]

Merci pour vos conseils.
Pour être un peu plus précis : une 15aine de tables, 100Mo Max, à la louche 200 requêtes/h, multi-user impératif
En fait l'accès à l'appli se fera via RDP.
J'aurais donc voulu un .exe avec un fichier comme base, car c'est un peu compliqué à expliquer, mais j'aimerais éviter l'installation d'un quelconque SGBD et c'est là que je ne sais pas si c'est possible.
Si je ne trouve pas de solution assez souple et sans trop de contraintes, ben tant pis, j'en ferai mon deuil et passerai comme d'hab sur Sql Server.

vu la volumétrie, si tu t'en sens capable, ça tient en mémoire, tu coupe l'appli en deux un service avec la base, l'appli dessus, en ouvrant le service tu fais tu concurent

[François M.]

vu la volumétrie, si tu t'en sens capable, ça tient en mémoire, tu coupe l'appli en deux un service avec la base, l'appli dessus, en ouvrant le service tu fais tu concurent

Ca peut être une solution mais il faudra bien qu'il gère la persistance à un moment donné, et on ne connait pas son niveau de criticité de ce coté.

[Pol63]

La solution évitant l'installation est d'utiliser LocalDb.

ca n'évite en rien une installation, c'est un setup de quelques centaines de Mo

la question serait surtout pourquoi il ne veut pas installer sql server ?
il nous manque aussi le nombre de user max (et si le nombre de requetes /h est par user ou tout user confondu)

j'aime pas access, mais il semble pouvoir convenir (même si sql server serait mieux, le meilleur n'étant pas toujours nécessaire)

[François M.]

ca n'évite en rien une installation, c'est un setup de quelques centaines de Mo

Oups, exact.

j'aime pas access, mais il semble pouvoir convenir (même si sql server serait mieux, le meilleur n'étant pas toujours nécessaire)

Oui, mais Access doit être installé aussi.
Dans ce cas, autant installer Sql Server Express (et ça évite les bizarreries d'Access en terme de SQL, etc ..)

[Pol63]

access n'a pas besoin d'être installé, comme dit précédemment jet (x86) est présent avec windows

[François M.]

access n'a pas besoin d'être installé, comme dit précédemment jet (x86) est présent avec windows

C'est vrai; mais comme il ne m'était jamais venu à l'idée d'utiliser ce machin (sauf pour accéder en mode Db à des classeurs Excel), je l'avais quelque peu oublié.

Ce ne change rien au fait que son accès concurrent est quand même très bricolo. (on est en mode fichier)

[Pol63]

C'est vrai; mais comme il ne m'était jamais venu à l'idée d'utiliser ce machin

c'est vrai qu'autant des trucs qu'on ne connait pas, on ne pense pas à les utiliser, mais là même en le connaissant c'est difficile d'y penser quand même ^^

sauf pour accéder en mode Db à des classeurs Excel

en .net on peut accéder directement à un fichier excel avec system.data.oledb, comme pour une base access (tout le CRUD fonctionne, create table créé une feuille ...)
et c'est d'ailleurs énormément plus performant que de l'interrop

[François M.]

en .net on peut accéder directement à un fichier excel avec system.data.oledb, comme pour une base access (tout le CRUD fonctionne, create table créé une feuille ...)

Je parlais de l'accès en utilisant une connexion Jet OleDB, bien sur, pas de l'interop. (qui de plus ne peut - enfin ne doit pas ... - être utilisé sur une appli serveur du fait de ses problèmes récurrents de stabilité).

[pascalCH]

Ca peut être une solution mais il faudra bien qu'il gère la persistance à un moment donné, et on ne connait pas son niveau de criticité de ce coté.

Perso sur une liste de liste d'objet, je prend la serialisation XML associée à un timer.

[François M.]

Perso sur une liste de liste d'objet, je prend la serialisation XML associée à un timer.

Ce qui suppose un niveau faible de criticité (tu ne vas pas persister 100 Mb toutes le secondes).