Navigation

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

Visual Studio Discussion :

Base de données intégrée. Trop de choix?


Sujet :

Visual Studio

  1. #1
    Futur Membre du Club
    Base de données intégrée. Trop de choix?
    Bonjour à tous,
    Je dois développer pour mon usage personnel une petite application winforms, qui exploitera et modifiera les données d'une base de données suffisamment simple et petite pour que j'envisage de la créer directement dans Visual Studio et de l'intégrer directement à l'application, pour en outre éviter d'avoir à déployer un SGBD sur le poste utilisateur.
    Or, il semble y avoir des tas de possibilités: Des SGBD (SQL Server Express, SQlite...), les Datasets,
    Pour l'accès et la manipulation des données, c'est pareil: ADO, LINQ, Entity Framework...
    Malgré mes recherches, par exemple cette page, je ne m'en sors pas. Comment choisir?

  2. #2
    Expert éminent
    Bonjour,

    Tout dépend de l'application, de son utilisation, mais aussi du but de son écriture.

    Si c'est à usage purement perso, mono-poste, mono-utilisateur, pas de partage de données entre utilisateurs, etc. alors SQLite :
    https://sqlite.org/index.html
    Il est intégré à Visual Studio, et porté sur n'importe quelle plateforme (donc que tu fasses du Windows.Forms sous Windows, Xamarin.Forms sous iPhone, ou du .NET Core sous Linux, alors pas de souci, SQLite sera disp). Il est totalement intégré au programme, donc pas d'installation séparée.

    Si c'est mono-poste et mono-utilisateur, mais pourrait un jour être multi-poste (plusieurs instances du programme qui accèdent à la même base, genre d'un côté un téléphone, un PC et un site web), ou multi-utilisateur (plusieurs utilisateurs accèdent à la base avec des droits différents), alors surtout pas SQLite car il n'est pas prévu pour.
    A ce moment, SQL Server (Express ou Developper si c'est pour une utilisation perso ou de formation) sont adaptés.

    Pour le reste, j'ai envie de te dire que c'est avant tout une guerre de religion ou pour répondre à un besoin dans un SI existant : aucun intérêt particulier d'aller vers d'autres outils que ces deux là si tu n'as pas une contrainte qui t'y oblige.


    Pour ce qui est du connecteur, j'ai envie de dire :
    - Connecteur natif quand existant (Par exemple SqlConnection)
    - OleDb si possible (Par exemple OleDbConnection)
    - Odbc en dernier recours (par exemple OdbcConnection)

    En effet, d'un point de vue performances et complétitude, c'est généralement dans cet ordre qu'ils sont les meilleurs.

    Par exemple avec SQL Server, le connecteur natif et OleDb sont complets, mais Odbc ne supporte pas les paramètres nommées (il me semble, j'ai un doute soudainement).

    Enfin, si tu découvres, je te conseille de commencer en mode "old school" avec une base modélisée à la main (create table, etc.) et du code d'accès aux données écrit à la main (SqlCommand, etc.) afin de bien comprendre les mécanismes derrière la magie des framework d'accès aux données.

    Si c'est pour approfondir tes compétences, ou un besoin particulier, tu peux te lancer dans Entity Framework ou MVC et faire du "code first" (attention, si tu veux faire de la merde, c'est ce qu'il y a de mieux).
    On ne jouit bien que de ce qu’on partage.

  3. #3
    Futur Membre du Club
    Merci pour cette réponse complète, j'y vois plus clair!