Quel SGBDR pour une utilisation totalement déconnectée ?

**davcha** · 20/05/2006, 12h47

Une application va devoir manipuler des données (références d'articles, bons de commande, clients...) de manière totalement déconnectée.

En effet, cette application est destinée, entre autre, à être utilisée à partir d'ordinateurs portables ne disposant d'aucune connexion réseau, pour la simple raison que ces ordinateurs portables sont destinés à être utilisés en dehors de l'entreprise : chez le client, par exemple.

Certaines données seront créées à partir de ces ordinateurs portables (comme les bons de commande), alors que d'autres seront créées sur un serveur de données.
Les données créées sur le serveur de données servent, entre autre, à fournir une base de travail pour les ordinateurs portables.
Il doit être possible de rappatrier les données créées à partir des ordinateurs portables, sur le serveur de données.

Bref, en résumé, j'ai une base de donnée centrale qui fournit les données aux ordinateurs portables, leur permettant de travailler.
Cependant ces ordinateurs portables doivent fonctionner sans la base de donnée centrale, ce qui signifie que ces ordinateurs portables doivent disposer d'une copie locale, partielle, de la base de donnée centrale.

Une fois les travaux effectués sur un ordinateur portable, les données générées par celui-ci doivent être rappatriés sur la base de donnée centrale.

Sachant que j'aimerais éviter, évidemment, d'avoir à installer un serveur SQL sur chaque portable, et que lors du rappatriement des données portable --> serveur, l'unicité des données et les diverses contraintes doivent être respectées....

Exemple...
J'ai mon serveur de donnée, dans ce dernier, j'y stocke tous les articles, leurs références etc... Les clients, les bons de commandes créés par le passé...
J'importe partiellement ces données (en fait les articles, leurs références, et certains clients) sur une copie locale sur un ordinateur portable.
Avec l'ordinateur portable, je vais chez un client, je lui fais son bon de commande, et une fois ce travail fait, je reviens près du serveur de données, et je rappatrie les données nouvellement créées (le bon de commande) sur le serveur de donnée.

Le problème qui va se poser lors de l'opération de rappatriement est que je risque d'avoir deux bons de commandes avec le même identifiant, par exemple. Ce que j'aimerais également éviter autant que possible.

Quel SGBDR me conseillez-vous pour le serveur de données et les ordinateurs portables ?

**ePoX** · 21/05/2006, 20h53

Il y'à une petite précision que tu ne donnes pas.
L'application utilise t'elle une interface de ton cru, ou utilisera t'elle un navigateur ?

J'imagine que ce sera la première.
Dans ce cas la pourquoi ne pas utiliser access ou SQLite ?
Sinon tu peux jeter un oeil à cette page http://fr.wikipedia.org/wiki/SGBD, je n'ai pas tout regarder, mais je pourrai citer hyperfile qui fait du monoposte aussi apparemment.
Après il faut voir quel langage sera utilisé pour savoir si des drivers sont dispos.

Sinon pour l'identifiant de bdc, parles tu de l'identifiant automatique de la bdd, ou de la référence du BDC ?
Dans le cas de la référence si tu n'as pas de restrictions particulières à ce sujet.
Pourquoi ne pas ajouter l'identifiant du commercial dans la référence du bdc ?
Avec un information tels que l'année+mois+jour+un random sa devrait le faire.

Si tu est restreint au niveau du format de la référence, le souci qui vas se poser est que le commercial ne pourra pas émettre le BDC, puisque la référence changeras peut être lors de l'importation dans la bdd principale.
En effet si lors de l'import tu trouves une référence en double, tu en régénérera une nouvelle pour ce bdc.
Hors si jamais le commercial à émis le BDC, le système se vautre en beauté.
Donc la souci... :/

Si tu parlais de l'id généré par la bdd.. J'ai envie de dire que la synchro entre les postes de commerciaux et la bdd principale devrait se faire sur la référence de BDC, en effet celle-ci sont unique.

Enfin voila, en espérant t'aider un peu

bbye

**davcha** · 21/05/2006, 22h52

En fait, il s'agira d'une interface de mon cru, en utilisant le langage c# avec le framework .NET 2.0.

Sinon, j'ai réglé nombre de problèmes vis à vis des contraintes d'unicité etc, du rappatriement des données. En effet, j'ai rediscuté avec mon client, et on a réglé tous ces problèmes là.

Cependant, je retiens l'idée de la clef primaire timestamp+random, très bonne idée, merci

Il me reste donc une seule et unique question : quel SGBDR fichier utiliser ?
En effet, un SGBDR client/serveur ne fera pas du tout l'affaire, il est vraiment nécessaire d'utiliser un SGBDR fichier, genre access....

En revanche, j'ai pas de très bons souvenirs d'access. Je dis pas que c'est MÂÂÂAAL

, mais de ce que je me souviens de l'époque où je l'utilisais, c'était relativement lent et ça gérait encore moins de choses que MySQL 3. Ca a peut-être changé depuis ?

Sinon, j'ai entendu dire que firebird fournissait à la fois un SGBDR client/serveur et un autre SGBDR fichier ?
J'ai également entendu parlé d'une comparaison access/sql server... sql server fournirait-il une gestion de base de données fichiers, malgré son nom ?

**ePoX** · 21/05/2006, 23h52

J'avoue ne pas trop utiliser access donc je ne sais pas :s

Sinon en fouinant un peu
http://www.developpez.net/forums/arc...p/t-14343.html
http://fadace.developpez.com/sgbdcmp/#Description

FireBird à l'air sympa selon le comparatif trouvé sur DVP, puisque l'utilisation se ferait via une dll. Donc pas d'odbc machin truc.

Sinon en terme de performance, je suis bien incapable de ton conseiller. Je n'ai strictement aucune connaissance à ce niveau la.

:/

bbye

**Alexandre T** · 22/05/2006, 21h25

Je te conseille tout serveur savant gérer des fichiers plats.

Par exemple, mysql et la commande LOAD INTO FILE te permet d'insérer très rapidement dans la base de données un volume plutôt conséquent de données. Il existe des notions similaires en Oracle et sans aucun doute sur d'autres SGBDR.

Autre piste, as-tu pensé à la réplication de données, via des serveurs sgbd esclaves sur chaque poste client qui se synchronise à leur retour sur le serveur maître ?

Enfin, pour le timestamp+random en clef primaire, je te le déconseille. Il est préférable d'utiliser une colonne unique TIMESTAMP + RANDOM (très bonne idée qui évite très facilement les doublons), mais je conserverais tout de même une clef primaire qui s'autoincrémente seule au moment de l'import de tes données sur le serveur. En effet, après sur le serveur les comparaisons sur une chaîne de caractère de type timestamp+random sera toujours plus longue/lente qu'une comparaison de deux entiers !

**GrandFather** · 22/05/2006, 22h28

Bonjour,

si la volumétrie le permet, pourquoi ne pas envisager l'emploi de XML pour stocker les données sur les portables ? Les performances ne seront évidemment pas les mêmes qu'avec un SGBDR (c'est pour cela que je parle de volumétrie), mais les fonctionnalités apportées par XPath et XQuery valent, je pense, que tu étudies la question...

XML est supporté en format d'importation/exportation par beaucoup de SGBDR, et s'il faut faire un peu de conversion XSLT est là pour ça.

**SQLpro** · 23/05/2006, 10h04

je vous conceille de vous orienter vers un SGBDR qui sait gérer de la réplication. Par exemple pour cela vous pouvez utiliser un serveur MS SQL Server 2005 en base centrale et des run time SQL Server Express (gratuit). Vous ne modifiez rien de vos tables et activez une réplication (il existe 5 modes différents de réplications dans SQL Server).

Ce sera plus propre et garantit !

Que se passe t-il si votre serveur central tombe en panne au milieu d'une session de rélication ?

A +

**davcha** · 23/05/2006, 14h04

En fait j'aimerais autant que possible éviter d'avoir un système demandant une grosse maintenance, particulièrement pour les portables.

J'aimerais, par exemple, éviter d'avoir à installer un SGBDR sur chaque portable.

Concernant les fichiers XML, j'y avais pensé, mais la volumétrie sera sûrement trop importante (10 à 50 000 lignes pour certaines tables, ça commence à faire beaucoup quand même).

Toujours dans le même esprit "d'absence de maintenance autant que possible", l'idée d'un SGBDR fichier me parait appropriée, dans la mesure où, les utilisateurs finaux n'ont que peu (voir pas) de compétences dans ce genre de domaine.
Répliquer une base de donnée, faire des sauvegardes à partir d'un SGBDR client/serveur, tout ça... leur paraîtra sûrement beaucoup plus compliqué que de copier un simple fichier.

**Marc Lussac** · 23/05/2006, 14h18

Tu te complique pour rien

Il existe des SGBD qui prennent peu de ressources, qui sont faciles à installer et ne demandent aucune maintenance, et qui peuvent fonctionner en base répartie : base locale / base distante.

Exemple : FirebirdSQL (ex interbase)

**SQLpro** · 23/05/2006, 16h38

1) une réplication une fois installée et à condition que les bases soient proprement modélisée => aucune intervention
2) les SGBDR à base de fichiers sont les plus vulnérables à la fois aux problèmes de corruption OS et aux erreurs des utilisateurs (effacement par erreur d'un fichier). Dans ce cas l'erreur est généralement irrécupérable.

A +