Installer application Visual Studio Community 2015 avec base SQL Server 2014 Express sur poste vierge

Bonjour,
Je souhaite développer une application VB (Visual Studio Community 2015) qui utilise une base de données (SQL Server 2014 Express) sur un poste de développement.
J'ai terminé la base de données comprend 16 tables (avec relations), 5 tables principales et 10 tables de type liste de valeurs ainsi que 4 vues et contiendra quelques milliers d'enregistrements pour certaines tables.
Cette application sera utilisée par une seule personne et sur un autre poste (toujours le même) qui utilisera la base de données en lecture et écriture

Je voudrais installer cette application sur ce poste"utilisateur" avec le minimum de composants, tout en prévoyant des mises à jour (corrections et évolutions)

Avez-vous des conseils ? Par exemple, composant ou méthode utilisés pour l'accès à la base de données ?
Pouvez-vous m'indiquer la marche à suivre pour l'installation ?

D'avance, merci pour vos retours

J'ai pas très bien compris : "sera utilisée par une seule personne et sur un autre poste"
=> Une seule personne qui accède à l'application depuis deux postes différents ?
=> Deux postes qui accèdent à la même base de données en simultané ?

Pour ce qui est du programme VB, une fois compilé, vous pouvez générer un setup dans lequel vous pouvez mettre en dépendance SQL Server Express.

Ainsi, il n'y aura rien à installer de plus que le setup.exe généré par Visual Studio.

Merci pour ce premier retour.
Ce que je voulais dire : L'application sera utilisée par une seule personne et toujours sur le même poste (différent du poste de développement)

De plus ce poste ne sera pas connecté au poste sur lequel la base de données à été créé à l'initial.
Donc que faut-il prévoir pour la base de données ? Faut-il la créer (ou l'installer) sur le poste cible ?
Faut-il prévoir l'installation de SQL Server Express sur le poste cible ?

De plus avez-vous des conseils de développement ? Par exemple, composant ou méthode utilisés pour l'accès à la base de données ?

Plutôt que SQL Server Express, optez plutôt pour LocalDB : SQL Server et la base ne seront chargés en mémoire que durant l'utilisation du programme.
=> Légèrement plus lent au démarrage du programme, charge inférieure du poste, surtout si le programme n'est pas utilisé en permanence.

Les fonctionnalités sont les mêmes entre LocalDB et Express : la seule différence c'est que LocalDB ne répond pas sur le réseau, et que l'instance est chargée "à la demande" plutôt qu'à l'aide d'un service.

Pour ce qui est de la création de la base, il y a deux solutions.
Les deux ont leur avantages et leurs inconvénients.

1/ Déployer un backup de la base de données, ou carrément les fichiers *.mdf et *.ldf prêts à être montés.
=> Plus simple. En revanche, en cas de mise à jour du modèle des données, vous perdez tout le contenu de la base.

2/ Déployer des fichiers SQL "version par version" contenant les instructions pour créer/modifier les objets de la base de données. Par exemple, en V1, vous avez que des "create table ..." et dans la V2, vous avez quelques "create", quelques "drop" et surtout beaucoup de "alter".
=> L'avantage c'est que vos scripts peuvent transformer les données existantes pour les adapter de l'ancien modèle au nouveau modèle. En contre-partie, le boulot est un peu plus fastidieux car vous devez écrire et maintenir ces scripts, et soit les lancer à la main au moment de l'installation, soit intégrer un module de patch dans votre programme (au démarrage, le programme vérifie la version de la base de données, et joue les scripts de modification si nécessaire).

Sinon, mise à part choisir C# en lieu et place de VB.NET, je n'ai pas trop de conseil de développement si ce n'est :
- Utilisez absolument le connecteur natif .NET plutôt que OLEDB ou autre ODBC (plus performant et meilleur support)
- Si demain vous devez travailler avec d'autres bases (Oracle, MySQL, Postgre, Access, DB2, osef) optez pour l'utilisation des interfaces plutôt que les classes directement dans toutes les couches "consommatrices".
- Optez sans aucune hésitation pour des requêtes paramétrées, et usez et abusez de vues et procédures stockées (cf. l'article dans mon blog)
- A chaque accès à la base de donnés, ouvrez et fermez explicitement la connexion à la base : .NET va faire du pooling automatiquement derrière, et ça évitera de conserver des sessions inutiles dans la base quand l'utilisateur part en pause déjeuner (bon, sur un LocalDB, c'est moins critique que sur un serveur centralisé)
- Gérez vos transactions le plus bas possible (dans une procédure stockée par exemple) plutôt qu'à travers les couches métier de votre programme : vous éviterez les dead lock
- J'oubliais : utilisez le compte Windows de l'utilisateur pour accéder à la base plutôt qu'un login/pass stocké en clair dans une chaîne de connexion (puis un autre stocké dans une table pour savoir qui est connecté à l'application)

Re bonjour et re merci pour ces conseils et infos.
Quelques questions, avant de déclarer le sujet "résolu", sur votre conseil suivant :

Plutôt que SQL Server Express, optez plutôt pour LocalDB

- J'ai déjà installé SQL Server 2014 Express sur le poste de développement, dois-je installer autre chose (LocalDB par ex.) et faut-il désinstaller SQL Server 2014 Express ?
- La base de données est déjà créé, que faut-il faire pour la "passer" en LocalDB ?

A propos des vues, je pensais n'accéder à la base qu'au travers de vues et seulement à des tables dans le cas de gestion de tables secondaires comme des listes de valeurs (code - libellé).
- Est-ce la bonne méthode ?

N'étant pas du tout spécialiste, je vais lire votre article sur les procédures stockées, car j'avais bien l'intuition que cela permet de regrouper le code sur la partie données !
- Avez-vous un lien ?

Citation:

---

Envoyé par Michel Trebor

- J'ai déjà installé SQL Server 2014 Express sur le poste de développement, dois-je installer autre chose (LocalDB par ex.) et faut-il désinstaller SQL Server 2014 Express ?
- La base de données est déjà créé, que faut-il faire pour la "passer" en LocalDB ?

---

Si vous avedz déjà installé SQL Server Express, vous pouvez laisser comme ça.
L'intérêt de LocalDB, c'est surtout de pouvoir le packager plus facilement (et réduire les soucis d'installation).

Citation:

---

Envoyé par Michel Trebor

A propos des vues, je pensais n'accéder à la base qu'au travers de vues et seulement à des tables dans le cas de gestion de tables secondaires comme des listes de valeurs (code - libellé).
- Est-ce la bonne méthode ?

---

La méthode préconisée est avant tout de ne jamais accéder aux tables directement.
Ceci pour la simple raison que si demain :
- Vous voulez mettre en place une gestion des droits avancée (par exemple donner accès à certaines colonnes et pas à d'autres)
- Votre modèle de données évolue
- Vos règles de gestion et d'intégrité évoluent
=> Alors il vous faudra réécrire la moitié du code de votre programme, y compris au niveau de la couche métier.

Si vous passez par des vues et des procédures stockées/triggers pour accéder en CRUD (create / retrieve / update / delete) à vos données, alors vous n'aurez pas autant de code à modifier en cas de changements, y compris importants au niveau de la structure des données.

Citation:

---

Envoyé par Michel Trebor

N'étant pas du tout spécialiste, je vais lire votre article sur les procédures stockées, car j'avais bien l'intuition que cela permet de regrouper le code sur la partie données !
- Avez-vous un lien ?

---

Mon article n'est pas spécialement à propos des procédures stockées. Il traite surtout de la mise à jour du modèle des données sans réécrire une ligne de l'application cliente. Il explique donc comment faire abstraction du modèle physique des données (agencement des tables et des colonnes dans la base) pour exposer les objets spécifiquement nécessaires à l'application sous forme de vues et de triggers.
Le lien, vous devriez le trouver sous mon avatar (ou au dessus, là où y'a marqué "blog" ^^)

Petite précision, j'ai déjà installé SQL Server Express sur mon poste de développement mais aucune installation sur le poste cible.
Je pensais avoir compris que LocalDB devait faciliter l'installation de l'application et de la base de données sur le poste cible et je veux privilégier une installation simple et minimale sur ce poste cible et donc d'utiliser LocalDB.

Mes dernières questions concernait les modifications que je dois apporter au poste de développement :
- Faut-il réinstaller SQL Server Express avec l'option LocalDB ou ajouter simplement LocalDB ou ... ?
- Une fois LocalDB installé ou activé, faut-il refaire la création de la base de données ? dans ce cas je peux peut-être modifier (si nécessaire) et exécuter les scripts SQL que j'ai enregistré

Non, rien besoin de toucher sur le poste de développement.
Seule la chaîne de connexion change entre une instance et LocalDB.

Pour ce qui est de la base, le plus simple est de distribuer avec ton application les fichiers MDF et LDF (les deux) puisque lors du démarrage de LocalDB, on peut lui indiquer d'attacher une base (en indiquant le nom du fichier MDF) :
https://www.connectionstrings.com/sq...fic-data-file/

Code:

---

Server=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyFolder\MyData.mdf;

---

Merci pour ces réponses