Sécuriser les données d'une bdd accédée par plusieurs utilisateurs

Bonjour,
Voilà, j'ai réalisé un logiciel en java qui se connecte à une bdd oracle, plusieurs utilisateurs (5 en tout) l'utilisent et chacun d'eux à sa propre bdd sur son pc (je précise que nous travaillons tous dans la même entreprise et que nous sommes reliés à un réseau local). il se trouve que chaque utilisateur a besoin de consulter les données des autres, donc j'ai pensé à ne garder qu'une seule bdd sur l'un des pc et tous le monde va travailler sur celle-ci(insertion de nouvelles données, consultation...) et c'est là que ça coince:
1-faut-il utiliser des theads pour l'accès à la bdd : j'utilise un singleton pour la connexion et j'ai pensé à synchroniser la méthode getInstance(),mais ça voudrait dire(je pense!)qu'un seule utilisateur à la fois aurait accès à la bdd,ça va énormément ralentir leur travail!
2-vaut-il mieu laisser la chose telle qu'elle et faire régulièrement l'import et l'export des données de tous le monde, ça m'enchante pas non plus!
3-je précise que dans les meilleurs des monde! je voudrais que tout le monde puisse travailler en même temps mais sans qu'il y ait conflit de données!(le problème est précisément là)
donc si vous avez des idées n'hésitez pas à m'aider j'en ai besoin.
Merci beaucoup.

Citation:

---

Envoyé par kalina

1-faut-il utiliser des theads pour l'accès à la bdd : j'utilise un singleton pour la connexion et j'ai pensé à synchroniser la méthode getInstance(),mais ça voudrait dire(je pense!)qu'un seule utilisateur à la fois aurait accès à la bdd,ça va énormément ralentir leur travail!

---

Euh, si tu as 5 PC et qu'ils ont chacun leur programme, ça veut dire qu'il y a 5 programmes et que chacun a son instance, donc 5 instances. Il n'y a donc aucun problème de ce genre.

Citation:

---

Envoyé par kalina

2-vaut-il mieu laisser la chose telle qu'elle et faire régulièrement l'import et l'export des données de tous le monde, ça m'enchante pas non plus!

---

Une BDD centrale c'est l'usage... Mais en principe elle devrait être sur son propre ordinateur, que personne d'autre n'utilise. Éventuellement un serveur freenux plutôt qu'un PC classique.

Le mieux, c'est d'utiliser une base de données commune. Les problématiques de corruption des données que tu souleves sont des problematiques de BDD. Le mieux, c'est d'installer un PC avec la base et que tous les utilisateurs tapent dedans (si possible). Ca permet de ne pas bloquer tout le monde parce que le developpeur chez qui la BDD est installée à eteint son PC...
Avoir une base commune permettra aussi d'etre plus réactif (une modif faite par 1 personne est immediatement visible par les autres) et plus simple (comment gerer une modif d'un meme enregistrement par 2 utilisateurs différents lors de l'intégration dans le cas de 5 BDD qui sont sur chaque poste ?).

Quand aux modifications dans ton code, dans la plupart des cas, ca ne change rien de taper dans une base locale ou distante (seulement la chaine de connexion). Mais bon, ca dépend du programme. On peut imaginer un programme qui part du principe qu'il est seul au monde et qui bug lorsqu'un utilisateur lit la base pendant qu'un autre modifie un enregistrement. Mais bon, ca doit etre plutot rare...

Bonjour, et merci pour vos réponses.

Citation:

---

Euh, si tu as 5 PC et qu'ils ont chacun leur programme, ça veut dire qu'il y a 5 programmes et que chacun a son instance, donc 5 instances. Il n'y a donc aucun problème de ce genre.

---

je suis d'accord.

Citation:

---

Une BDD centrale c'est l'usage... Mais en principe elle devrait être sur son propre ordinateur, que personne d'autre n'utilise. Éventuellement un serveur freenux plutôt qu'un PC classique.

---

d'accord aussi, mais reste le problème de conflit de connées!

Citation:

---

Le mieux, c'est d'utiliser une base de données commune. Les problématiques de corruption des données que tu souleves sont des problematiques de BDD

---

d'accord, mais comment les régler? à noter que je préfèrerai n'utiliser ma bdd que comme source de données,mais s'il faut passer par là, je le ferai

Citation:

---

Avoir une base commune permettra aussi d'etre plus réactif (une modif faite par 1 personne est immediatement visible par les autres

---

c'est exactement ce que je veux! mais avec des données cohérentes! mais vous semblez minimiser la chose, dois-je en faire autant?
merci.

On comprend pas c'est quoi pour toi cohérent et incohérent ?

Tu as 5 utilisateurs et chacun a ses propres données. Chacun peut voir les données des autres, et chacun peut modifier ses propres données.
Ça veut dire que les données de chaque personne n'existent qu'en un exemplaire dans la BDD centrale, donc pas d'incohérence ici. Et qu'elles sont copiées sur demande vers chaque PC qui les demande, mais il suffit de ne pas les garder et juste les redemander à chaque fois, et il n'existe pas d'incohérence.

Alors de quoi tu parles ?

Citation:

---

Envoyé par kalina

d'accord aussi, mais reste le problème de conflit de connées!

---

C'est quoi le conflit de données pour toi ?
Si c'est l'accès en modification en meme temps qui pourrait corrompre la base, alors c'est bien la base de données qui s'occupe de gérer ca. Et Oracle à un petit peu d’expérience en ce domaine, il ne devrait pas y avoir de soucis.

Le probleme classique de conflit, c'est lorsque 2 utilisateurs affichent une meme fiche pour la modifier puis que l'un d'eux valide une modification. Que faire lorsque le 2e validera sa modif ? Dans ce cas, c'est à ton programme de définir le comportement voulu (afficher un message indiquant la modif, ne changer que les champs qui ont été modifiés, ...)

ben, par exemple il va arriver souvent que les utilisateurs insèrent des enregistrements tous en même temps dans la même table!(surtout si la clé de l'enreg est calculée à partir du nombre total des enreg de la table!)qu'est ce qui va en résulter? c'est de ça que je parle. Mais il y a surement des détails qui m’échappent, c'est bien pour ça que je demande de l'aide!
merci pour vos réponses.

Citation:

---

Envoyé par hwoarang

C'est quoi le conflit de données pour toi ?
Si c'est l'accès en modification en meme temps qui pourrait corrompre la base, alors c'est bien la base de données qui s'occupe de gérer ca. Et Oracle à un petit peu d’expérience en ce domaine, il ne devrait pas y avoir de soucis.

---

donc si je comprends bien je n'est pas à m'en mêler.

Citation:

---

Envoyé par hwoarang

Le probleme classique de conflit, c'est lorsque 2 utilisateurs affichent une meme fiche pour la modifier puis que l'un d'eux valide une modification. Que faire lorsque le 2e validera sa modif ? Dans ce cas, c'est à ton programme de définir le comportement voulu (afficher un message indiquant la modif, ne changer que les champs qui ont été modifiés, ...)

---

d'accord, mais comment mon programme va savoir qu'il y a eu une modif?
merci

Encore une fois, c'est à la base de données de gérer ces problématiques ;)

Les bases de données ont leur propre solution pour la solution de clef qui s'incrémentent (AUTO_INCREMENT pour MySQL, les séquences pour postgreSQL; je ne connais pas oracle).

Par contre toute gestion de l'incrémentation coté client (à base de MAX()+1) est en effet à proscrire dans un environnement multi-utilisateur.


Autrement, on utilise les transaction pour manipuler les données de manière isolées pour chaque utilisateur, et on les sauvegarde en une seule opération atomique avec un COMMIT.
La "sauvegarde" est soit réussie entièrement, soit annulée dans sa totalité (par un ROLLBACK de la transaction ne cours).

Citation:

---

Envoyé par Sebajuste

Encore une fois, c'est à la base de données de gérer ces problématiques ;)

---

ok,compris

Citation:

---

Envoyé par Sebajuste

Par contre toute gestion de l'incrémentation coté client (à base de MAX()+1) est en effet à proscrire dans un environnement multi-utilisateur.

---

c'est de ça qu'il s'agit, il faudrait que je revoie ça, mais parfois j'ai l'impression que c'est la seule solution.

Citation:

---

Envoyé par Sebajuste

Autrement, on utilise les transaction pour manipuler les données de manière isolées pour chaque utilisateur, et on les sauvegarde en une seule opération atomique avec un COMMIT.
La "sauvegarde" est soit réussie entièrement, soit annulée dans sa totalité (par un ROLLBACK de la transaction ne cours).

---

je vais voir ça, merci beaucoup.

Google Oracle Sequence -_-°

Citation:

---

Envoyé par kalina

c'est de ça qu'il s'agit, il faudrait que je revoie ça, mais parfois j'ai l'impression que c'est la seule solution.

---

Cette remarque ferais surement hurler nos DBA du forum des SGBD ^^

Je n'ai pas assez de compétence dans le domaine des base de données, mais les sytème d'incrémentation fournis dans les SGBDR doivent la plupart du temps suffire non ?

Rapproche toi du forum d'Oracle pour trouver une solution à ce problème spécifique.

En tout cas, il vaut toujours mieux laisser au SGBD toutes ces problématique d'accès concurrent. Ils sont fait pour, et sont donc bien mieux armés que nos petits soft développés pour d'autres tâches ;)

Citation:

---

Envoyé par Sebajuste

Rapproche toi du forum d'Oracle pour trouver une solution à ce problème spécifique.

---

Google Oracle Sequence :rouleau:

ok, pour la cohérence des données, c'est très clair merci à tous.:ccool:
mais reste la première partie de ma première question:

Citation:

---

1-faut-il utiliser des theads pour l'accès à la bdd : j'utilise un singleton pour la connexion et j'ai pensé à synchroniser la méthode getInstance()

---

d'après vos réponses je pense que ça ne sert pas à grand chose, corrigez-moi si je me trompe.
merci.

Citation:

---

Envoyé par kalina

d'après vos réponses je pense que ça ne sert pas à grand chose, corrigez-moi si je me trompe.

---

Tout à fait, ca sert à rien de changer à ce niveau la.

Pour enfoncer le clou, j'ajouterais qu'il FAUT utiliser un index auto increment plutot que le calcul qui aboutira soit à des rustines immondes (et compliquées), soit à des bugs. L'interet d'utiliser un SGBD n'est pas de l'utiliser comme on utiliserait un fichier texte. C'est d'utiliser au maximum ses fonctionnalitées.
Il faut bien comprendre que les questions que tu es en train de te poser, des gens chez Oracle (et chez les autres SGDB, d'ailleurs) se les sont deja posées et ils ont trouvé des solutions qu'il te faudrait des années à faire (pour un résultat beaucoup moins bien). Bref, ca sert a rien de réinventer la roue...

c'est compris hwoarang :D
merci à tous pour votre aide.:ccool: