Discussion :

[EmbaseZingué]

Bonjour,

Ayant pas mal parcouru ce forum au cours des années, je me permet de poser une question à laquelle je n'ai pas trouvé récemment de réponse.
Dans le cadre d'un projet de refonte d'un logiciel, je me retrouve confronté à un choix de SGBD.

- Ce logiciel et la base de données sont généralement sur le même poste. Il s'agit à l'heure actuel d'une base de données fichier qui n'est plus soutenue. Naturellement en envisageant son remplacement, j'aurais plutôt tendance à me tourner vers des bases de données portable : SQLite, SQL server CE (moins car plus maintenue)… Ceci convient parfaitement au client qui n'est pas du tout informaticien. Cela lui permet en cas de panne d'un poste de faire juste un copier/coller depuis une sauvegarde sur un nouveau poste et de relancer le logiciel sans avoir d'autre manipulation à faire.

- Lors de la refonte du logiciel, nous envisageons également d'avoir plusieurs postes et donc plusieurs logiciel pour une seule et même base de données pour des questions de sécurité, souplesse et d'architecture plus complexe. Néanmoins ce mode de fonctionnement semble contraire au fonctionnement précèdent de BDD fichier (et qui est surtout déjà installé et compris par le client)

Existe-t'il une base de données fichiers qui soit adaptée à un fonctionnement réseau et multi-client?
Existe-t-il une base de données serveur qui puisse être restaurer simplement [juste copie de sauvegarde (ou équivalent) sans installation logiciel ni paramétrage ] pour des non-informaticien ?

J'ai cherché dans les liens suivant :
https://www.developpez.net/forums/d1...-base-donnees/
https://fadace.developpez.com/sgbdcmp/

et parcouru un peu les forums sans trouver de réponse claire.

N'ayant qu'un niveau standard en BDD et ne connaissant pas tous le marché, Auriez-vous des idées?

Merci par avance.

[SQLpro]

Dans le cadre d'un projet de refonte d'un logiciel, je me retrouve confronté à un choix de SGBD.

- Ce logiciel et la base de données sont généralement sur le même poste. Il s'agit à l'heure actuel d'une base de données fichier qui n'est plus soutenue. Naturellement en envisageant son remplacement, j'aurais plutôt tendance à me tourner vers des bases de données portable : SQLite, SQL server CE (moins car plus maintenue)…

Ces outils sont destinés à des logiciels embarqués, c'est à dire dans un frigo, une missile ou un smartphone. Ils sont conçus pour n'avoir qu'un seul utilisateurs et supportent très mal la concurrence ! Donc,dans votre cas, à moins d'interdire de n'avoir plus d'un utilisateur simultané c'est hautement stupide car extrêmement dangereux….

Ceci convient parfaitement au client qui n'est pas du tout informaticien. Cela lui permet en cas de panne d'un poste de faire juste un copier/coller depuis une sauvegarde sur un nouveau poste et de relancer le logiciel sans avoir d'autre manipulation à faire.

- Lors de la refonte du logiciel, nous envisageons également d'avoir plusieurs postes et donc plusieurs logiciel pour une seule et même base de données pour des questions de sécurité, souplesse et d'architecture plus complexe. Néanmoins ce mode de fonctionnement semble contraire au fonctionnement précèdent de BDD fichier (et qui est surtout déjà installé et compris par le client)

Existe-t-il une base de données fichiers qui soit adaptée à un fonctionnement réseau et multi-client?

Aucune !

Existe-t-il une base de données serveur qui puisse être restaurer simplement [juste copie de sauvegarde (ou équivalent) sans installation logiciel ni paramétrage ] pour des non-informaticien ?

Oui et non. Pour les sauvegardes de la base et restauration c'est une seule commande simplissime en général. Pour la réinstallation du SGBDR, cela peut être packagé pour n'avoir juste qu'a appuyer sur un bouton et indiquer la répertoire d'installation...

J'ai cherché dans les liens suivant :
https://www.developpez.net/forums/d1...-base-donnees/
https://fadace.developpez.com/sgbdcmp/

et parcouru un peu les forums sans trouver de réponse claire.

N'ayant qu'un niveau standard en BDD et ne connaissant pas tous le marché, Auriez-vous des idées?

Merci par avance.

Optez pour SQL Server, car la plupart, voir presque tous les autres produits ne peuvent pas facilement être packagés en sus de devoir obliger à des intervention de paramétrage en bricolant des fichiers (notamment sous Linux…)

A +

[CinePhil]

Je ne sais pas s'il existe des solutions toutes faites par ailleurs mais, partant du principe qu'un utilisateur non informaticien est quand même capable de suivre une procédure si elle est bien rédigée, il est possible, avec MySQL / MariaDB ou PostgreSQL de faire une sauvegarde régulière de la BDD et de la réinjecter ailleurs.

Exemple avec MySQL / MariaDB...

1) Sauvegarde d'une BDD :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump -u [user ayant les privilèges mini pour permettre la sauvegarde de la BDD] -p[son mot de passe collé au -p] [nom de la BDD] > chemin/vers/fichier_de_sauvegarde.sql

2) Chargement d'une sauvegarde dans une BDD créée mais vierge sur un autre poste :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql -u [user ayant les privilèges mini pour permettre la sauvegarde de la BDD] -p[son mot de passe collé au -p] [nom de la BDD] < chemin/vers/fichier_de_sauvegarde.sql[

=> il n'y a que le nom du programme et le sens de la flèche qui change.

Il y a plein d'options à mysqldump. Voir la doc.

La commande de sauvegarde peut être mise dans un script exécutable et dans une tâche quotidienne. On prendra soin aussi de nettoyer les fichiers de sauvegarde si on les horodate.

Exemple de sauvegarde avec PostgreSQL :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

pg_dump [nom de la BDD > chemin/vers/fichier_de_sauvegarde.sql

La aussi, voir la doc pour pg_dump.

Il y a aussi des solutions peut-être encore plus rigoureuses puisque PostgreSQL génère des journaux de transaction mais je ne me suis pas encore penché sur le sujet.


Donc, en résumé :
1) Mettre en oeuvre une sauvegarde automatisée de la BDD
2) Écrire la procédure adéquate pour restaurer une sauvegarde en cas de crash.

[SQLpro]

Exemple avec MySQL / MariaDB...

1) Sauvegarde d'une BDD :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump -u [user ayant les privilèges mini pour permettre la sauvegarde de la BDD] -p[son mot de passe collé au -p] [nom de la BDD] > chemin/vers/fichier_de_sauvegarde.sql

2) Chargement d'une sauvegarde dans une BDD créée mais vierge sur un autre poste :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql -u [user ayant les privilèges mini pour permettre la sauvegarde de la BDD] -p[son mot de passe collé au -p] [nom de la BDD] < chemin/vers/fichier_de_sauvegarde.sql[

Mais va faire comprendre ces lignes de code atroce à des non informaticiens qui ne savent que appuyer sur un bouton ?
C'est pourquoi je conseille SQL Server dans lequel il est possible de tout faire par appui sur bouton….
Et en plus, vu les volumes, la version gratuite Express devrait suffire !


A +

[CinePhil]

Mais va faire comprendre ces lignes de code atroce à des non informaticiens qui ne savent que appuyer sur un bouton ?

C'est pour ça que j'ai fini mon message par :

Donc, en résumé :
1) Mettre en oeuvre une sauvegarde automatisée de la BDD
2) Écrire la procédure adéquate pour restaurer une sauvegarde en cas de crash.

Il faut que la sauvegarde soit transparente pour l'utilisateur et que le rattrapage de crash soit simple en lançant un programme qui va faire le boulot, ceci étant expliqué dans une procédure de reprise.

Mais c'est vrai que des fois on tombe sur des gens qui ont vraiment du mal... mais dans ce cas est-ce judicieux de leur confier une appli avec une BDD ?

[EmbaseZingué]

Merci de toutes vos réponses.

[StringBuilder]

Et sinon, pourquoi pas utiliser SQL Server LocalDB pour la version monoposte, et SQL Server Express ou Standard (selon le budget et les besoins) pour la version multiposte ?

L'avantage c'est qu'on peut distribuer la même base de données, toutes les requêtes et scripts sont compatibles d'un mode à l'autre, y'a que la syntaxe qui change !
Du coup même si on commence en monoposte, il suffit de monter la base de données sur un serveur puis changer la chaîne de connexion pour retrouver la base telle qu'elle, sans la moindre autre modification !