Discussion :

[Albert Camomille]

Bien le bonjour,

Je suis nouveau sur le forum, et j'ai bien chercher avant de venir me permettre de poster ici, mais je n'ai rien trouvé.

Pour me préquisenter rapidement, je suis en BTS SIO SLAM (ancien BTS Informatique de gestion) en 2ème année, j'ai étudié le C#, le SQL, le PHP, l'HTML et le CSS.

Depuis longtemps, je travail sur un projet perso: une appli qui me permettrait de gerer des parties de Donjon et dragons. (création de personnage, etc.)

J'ai choisis de mettre en place, un modèle de développement en couche. (BLL, DAL, BO et GUI). J'ai déjà bien avancé voir terminer la couche BO.
J'ai aussi bien avancer dans la couche GUI.

Mon problème pour mettre en place la DAL et la BLL. En effet, j'aimerais pouvoir donner ce programme à mes joueurs. Du coup je ne sais pas qu'elle gestionnaire de base de donnée choisir: Access, Sql Server, SQLite, Oracle?

Comme je voudrais pouvoir fournir ce programme à mes amis avec une base de donnée complète et utilisable j'ai cru comprendre qu'il faut que j'utilise plutot une Base de donnée embarquée style SQLite?

J'ai essayé de récupérer SQL server 2008 via DreamSpark (l'ancien MSDNAA) et SQL Server Express mais l'installation s'est trouvé tellement laborieuse que j'ai renoncé à utiliser SQL server.

Quel type de gestionnaire de base de donnée devrais-je utiliser?

Ensuite j'ai remarqué que la manière de se connecter à la BDD et de faire les requetes était différente entre SQL Server et SQLite.

Auriez vous des liens de tuto concernant cette partie? (la couche DAL en somme)

Merci d'avance!

[tomlev]

Comme je voudrais pouvoir fournir ce programme à mes amis avec une base de donnée complète et utilisable j'ai cru comprendre qu'il faut que j'utilise plutot une Base de donnée embarquée style SQLite?

Effectivement une BDD embarquée est sans doute le meilleur choix. Ca limite un peu tes choix :
- Access (mais je ne le recommande pas, c'est vraiment trop pourri)
- SQLite
- SQL Server Compact (qui contrairement au "vrai" SQL Server, ne requiert aucune installation)

J'ai essayé de récupérer SQL server 2008 via DreamSpark (l'ancien MSDNAA) et SQL Server Express mais l'installation s'est trouvé tellement laborieuse que j'ai renoncé à utiliser SQL server.

Ce n'est pas très adapté à ce que tu veux faire de toutes façons...

Ensuite j'ai remarqué que la manière de se connecter à la BDD et de faire les requetes était différente entre SQL Server et SQLite.

- Le langage SQL est essentiellement le même ; il y a de petites variantes selon les SGBD, mais grosso modo la syntaxe pour les SELECT/UPDATE/INSERT/DELETE est la même.
- Les chaines de connexion sont différentes (cf. ce site)
- On n'utilise pas les mêmes classes. Par exemple pour SQLite, on utilise SQLiteConnection à la place de SqlConnection, SQLiteCommand à la place de SqlCommand, etc. Pour SQL Server Compact, c'est SqlCeConnection, SqlCeCommand, etc. Sinon les principes restent exactement les mêmes, et en pratique tu peux (en grande partie) faire abstraction des différences, comme expliqué ici.

De plus il faudra ajouter une référence au provider ADO.NET adéquat. Le plus simple est de l'ajouter via Nuget

[DotNetMatt]

Juste pour compléter, attention avec la Compact Edition, car elle est principalement destinée aux applications pour smartphones. Les perfos sont sont relativement pourries et les fonctionnalités sont limitées...

Ca peut aller selon le projet (si par exemple tu ne fais pas trop d'appels à la base), mais ça peut devenir galère. A bien réfléchir donc si tu t'orientes vers SQL Server CE

[EDIT]Et je confirme, Access c'est vraiment à éviter.

[tomlev]

Juste pour compléter, attention avec la Compact Edition, car elle est principalement destinée aux applications pour smartphones. Les perfos sont sont relativement pourries et les fonctionnalités sont limitées...

Je sais pas où tu as pêché ça... ça marche très bien pour des applications PC ou même web, c'est pas du tout spécifique pour les mobiles. Et les perfs sont tout à fait correctes (comparables avec SQLite, voire meilleures dans certains scénarios)

[DotNetMatt]

Ben déjà on peut relever le fait que CE soit une base de données de type fichier, l'accès se fait via une DLL et la DB est chargée dans l'AppDomain. C'est donc déjà moins performant que quand on tape dans la RAM.

Enfin au niveau des fonctionnalités, il n'y a pas de procédures stockées par exemple, il y a une limite de taille, je crois que c'est 3 Go 2 Go.

Donc pour certaines applis ça peut faire l'affaire, mais pas pour toutes.

[EDIT] Après vérification, la limite de taille de la base de données CE est de 2 Go. J'ai corrigé ci-dessus.

[EDIT2] En complément, voici un lien qui recense les différences entre CE 3.5 SP2, CE 4, Express 2012 et LocalDB 2012 : http://erikej.blogspot.dk/2011/01/co...act-4-and.html

[tomlev]

Ben déjà on peut relever le fait que CE soit une base de données de type fichier, l'accès se fait via une DLL et la DB est chargée dans l'AppDomain. C'est donc déjà moins performant que quand on tape dans la RAM.

Enfin au niveau des fonctionnalités, il n'y a pas de procédures stockées par exemple, il y a une limite de taille, je crois que c'est 3 Go 2 Go.

Oui mais là tu compares des choses qui ne sont pas comparables ; bien sûr que SQL Compact a moins de fonctionnalités que SQL Server, et des moins bonnes performances, et une taille max pour la base, etc. C'est une DB embarquée, donc conçue pour être légère, donc forcément c'est moins puissant qu'une DB serveur.

Evidemment si Albert développait une grosse appli web, je recommanderais plutôt SQL Server, mais vu qu'il a clairement indiqué qu'il avait besoin d'embarquer la DB, SQL Compact est plus indiqué...