Réponse acceptée !
Bonjour,

A quoi penses-tu exactement dans la solution "B" quand tu parles de 'lien" vers ton application ?

En fait, dans ton cas, j'opterai pour la solution suivante :
- faire une architecture client/server -> mettre entre ton application (ton client) et ta base de données une autre application (le server). Seul le serveur accède à la base de données, et plusieurs clients dialoguent avec le serveur.
(tu peux aussi voir avec une architecture "n-tier", et remplacer le serveur par des "services" et rajouter d'autres couches d'abstraction, mais tu n'en pas nécessairement besoin...)

Même si la solution A est a priori envisageable, je te la déconseille, car a partir du moment ou plusieurs utilisateur accèdent à la même base de données, tu vas rencontrer les problèmes suivants :
- Modification simultanées d'une même information en base par plusieurs utilisateur (bon, normalement le base de données sait gérer ça)
- Plus globalement, problème de synchronisation entre le contenu de la base et ce que manipule l'utilisateur : imagine que 2 utilisateurs travaillent sur le même formulaire : si un utilisateur enregistre ses modifications, elles seront stockées en base de données, mais l'autre utilisateur continuera a travailler avec son formulaire, contenant les anciennes valeurs -> lorsqu'il enregistrera ses données, comment gérer le conflit ?

Le fait d'ajouter une couche entre la base de données et le client (c'est à dire rajouter un serveur) te permet de contrôler tout ça, et de valider ce que tu écris en base ou non. Par exemple, dans le cas précédent, le serveur peut déterminer qu'un utilisateur vient de modifier un formulaire, et "prévenir" (notifier) les autres utilisateurs de cette modification (ce que tu peux difficilement faire avec une base de données (même si ça reste techniquement faisable))

Par contre, une architecture client / server ammène un peu plus de complexité, notament dans la gestion des connexions entre clients et serveur, et encore plein d'autres choses :) Mais c'est quelque chose de classique donc les problèmes et les solutions sont bien connus...

Pour résumer, dans ton cas je regarderai du côté d'une architecture client server classique (3-tier), ou bien du côté d'une architecture n-tier, qui peut être aussi adaptée à ton problème.

---

Réponse acceptée !
Merci Nikoui pour ta réponse rapide et précise.

Concernant la solution B, je voulais en fait parler de raccourci vers le programme.

Le fait de rajouter une couche entre le client et la base permet en effet de maitriser d'avantage la cohérence au niveau des données, mais qu'en est-il du temps de réponse. Je tiens à ce que le caissier qui scanne son article ai une réponse instantanée (lorsqu'il récupère le prix de vente, le pourcentage de remise, le taux de tva, etc.). Le commerce en question est une supérette, les clients sont toujours pressés et peuvent être très nombreux à certaines heures...

Réponse acceptée !
Cette architecture ne te posera aucun problème de performance, surtout vu le contexte (a priori réseau dédié, et pas plus de quelques dizaines d'utilisateurs simultanés). De plus c'est vraiment une solution ultra classique pour ce genre de problématique, donc tu peux y aller les yeux fermés.

Attention par contre, c'est un peu plus complexe qu'une simple application qui va dialoguer directement avec une base de données, donc si tu débutes dans le domaine prévois du temps pour soigner le design et bien comprendre les tenants et les aboutissants.

---