+ Répondre à la discussion
Affichage des résultats 1 à 3 sur 3
  1. #1
    Invité régulier
    Inscrit en
    juillet 2003
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : juillet 2003
    Messages : 15
    Points : 6
    Points
    6

    Par défaut Séparation des données client

    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

  2. #2
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 899
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 899
    Points : 25 044
    Points
    25 044

    Par défaut

    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 !

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 667
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 667
    Points : 30 280
    Points
    30 280

    Par défaut

    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 :
    • i modulo n pour la graine
    • n pour le pas

    Il n'y a ainsi aucun chevauchement de clefs.

    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 * * * * *

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •