|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité régulier
![]() Inscription : juillet 2003 Messages : 15 ![]() |
Bonjour,
Voici le problème : Actuellement, nous gérons une base de données avec des tables dont certaines données peuvent être mutualisées à tous nos utilisateurs et d'autres spécifiques à certains utilisateurs. Grossièrement : Table A = données(client 1) + données(client 2) + données (global à tous les utilisateurs) Or, nous devons faire face de plus en plus à des problématiques telles que : - l'exportation et l'importation de données (problème d'id gérés avec auto_increment, complexité car nombreuses tables liées,etc.) - la synchronisation des données client entre deux bases de données qui évoluent distinctement (problèmes similaires au point précédent) - la mise à jour de nos propres données (mutualisées à tous nos clients) dans des bases de données dont le contenu diffère (mais reste tjrs sur un même schéma) Pour vous illustrer un problème : Nous gérons l'ensemble des données client sur nos serveurs (et donc par Internet). 50% des utilisateurs d'un client ne peuvent qu'accéder à leur réseau intranet, 50% des autres à l'intranet et internet. Cela nous oblige donc à installer nos applications sur leur intranet, d'où les soucis évoqués précédemment pour synchroniser leurs données avec leur serveur intranet. S'il existe un peu de littérature ou des conseils sur ce genre de problématique, je suis preneur... Le gros du problème étant les conflits avec les identifiants uniques de nos lignes en bd. ps : pour le moment, j'ai dans l'idée de partir sur une gestion manuelle de ces fameux identifiants uniques auto incrémentés... mais vu le travail, je préfère prendre des précautions Merci d'avance |
|
|
00
|
|
|
#2 |
![]() ![]() |
De plus experts que moi sauront mieux te répondre mais j'ai déjà vu un sujet similaire il y a pas mal de mois.
Pour autant que je me souvienne, l'idée était que chaque BDD a ses propres identifiants et la BDD centralisée a en plus des colonnes stockant l'identifiant utilisé par le client et l'identifiant du client. Le client 'Dupont' est identifié par le numéro 1 dans la BDD centrale. Il utilise ses propres identifiants de 1 à n dans sa BDD. La BDD centrale importe les données du client A sous la forme du triplet {id_central, id_client, id_utilise_par_client} => 3672, 1, 1254 = la ligne 3672 d'une table de la BDD centrale qui est relative au client numéro 1 (donc 'Dupont') et à la donnée de la table correspondante chez le client et portant l'identifiant 1254 dans cette table.
__________________
Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur. Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework... « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau) À la maison comme au bureau, j'utilise la suite Linux Mageïa ! |
|
00
|
|
|
#3 |
![]() ![]() ![]() Frédéric BROUARDExpert SGBDR & SQL Inscription : mai 2002 Messages : 12 166 ![]() |
Autre possibilité : l'intercalage de clefs. En gros sur n serveurs numérotés pour i allant de 0 à n-1, chaque table à une clef autoincrémenté dont les paramètres sont :
Autre solution : utiliser des bases de données réparties avec un système de communication comme service broker. Mais là il faut revoir toutes votre architecture de données. A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
|
00
|
Copyright © 2000-2013 - www.developpez.com