Synchronisation de 2 tables : quel objet ?

Bonjour,

je veux synchroniser 2 tables de structures identiques d'une base de données , une distante et une locale. Pour ce faire, je charge 2 champs de chaque table, ('id' et 'datestamp') dans 2 objets différents (Array of record, arrLoc et arrDst) puis je les compare ce qui me permet de construire 3 Strings : slINS, slUPD et slDEL qui correspondent aux actions engagées ensuite par le query dans la table cible (insertion, update ou suppression).

Je cherche à optimiser la procédure de comparaison des 2 objets. Que le premier objet ne soit pas trié est indifférent. Mais pour le second, pour les méthodes de comparaisons (recherche d'un enregistrement), j'en suis resté à l'obligation de celle de tris (rangé par ordre croissant).
Je précise que mes 'id' ne sont pas des entiers mais des chaînes : pour avoir subi des désagréments avec des id auto-incrémentés, j'ai préféré un système de chaînes.

Concrètement, la méthode lit un id de arrLoc et le cherche dans arrDst. Soit il n'existe pas dans arrDst (>>slINS), soit il existe et je compare les 'datestamp'. C'est la méthode de recherche que je cherche à optimiser et je pense qu'elle est dépendante de la nature de l'objet arrDst. Je ne sais pas si un array of record est le plus adapté.

Merci. Zac

Oui, cela n'inspire personne :aie:

J'ai tenté 2 approches :

• une fonctionnelle dont je ne suis pas trop fier : je charge l'id et le stamp de la table distante dans 2 tableaux différents (synchronisés) pour effectuer une recherche aisée et rapide sur l'id. J'ai essayé avec un multiArray, la recherche sur multiArray[0] me semble délicate. :oops:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

type TDstID = array of string; TDstSTAMP = array of string; TLoc = Array of array of string;   [..] SetLength(TLoc, 2); SetLength(TLoc[0], tableLoc.Count); SetLength(TLoc[1], tableLoc.Count); SetLength(TDstID, tableDst.Count); SetLength(TDstID, tableDst.Count);

---

Un QuickSort classique sauf au niveau du swap des données pour maintenir les 2 tableaux simples synchronisés. Au moment du swap dans le QuickSort :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

procedure QuickSort(var id: TDstID ; st : TDstSTAMP; Start, Stop: Integer); [...] begin idtmp := id[Left]; id[Left] := id[Right]; id[Right] := idtmp; sttmp := st[Left]; st[Left] := st[Right]; st[Right] := sttmp; Inc(Left); Dec(Right); end;

---

Une fois le tri effectué, je peux utiliser une function BinSearch(id: TDstID; ToSearch: string): Integer;

• Parce qu'initialement j'avais prévu autrement

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

uses Generics.Collections, Generics.Defaults; type TSynchro = record id: string; stamp: string; constructor Create(const aId, aStamp: string); end;   var DstArray: array of TSynchro;   implementation constructor TSynchro.Create(const aId, aStamp: string); begin id := aId; stamp := aStamp; end;

---

Pour le remplissage

Code:

---

1 2	SetLength(DstArray, tabledst.Count); DstArray[x] := TSynchro.Create(id, stamp);

---

Pour le tri obligatoire avant le BinarySearch, je n'ai pas rencontré de problème
{http://docwiki.appmethod.com/appmethod/1.16/libraries/en/System.Generics.Collections.TArray.BinarySearch}
//Note: BinarySearch requires that the array be sorted.

Code:

---

1 2 3 4 5

TArray.Sort<TSynchro>(DstArray , TDelegatedComparer<TSynchro>.Construct( function(const Left, Right: TSynchro): Integer begin Result := CompareText(Left.id, Right.id); end));

---

Mais pour trouver le N° de la ligne de idvalue, c'est la cata :oops:

Code:

---

1 2 3 4

FoundIndex : integer; TArray.BinarySearch<TSynchro>(DstArray, idvalue(string), FoundIndex, TDelegatedComparer<TSynchro>.Construct( ???? )); ShowMessage(IntToStr(FoundIndex));

---

Impossible de définir la fonction de recherche. C'est peut-être simple, peut-être impossible (avec record)...Je n'ai pas osé poser directement la question au risque de passer pour un idiot ou abuser du forum, je me lance quand même :?

Merci. Zac.

Bonjour,

Citation:

---

Oui, cela n'inspire personne

---

parce que pour moi (et certainement d'autres) la réplication de base de données (oui, c'est le vrai terme) ce n'est pas vraiment ma tasse de thé ;)
et que sans connaitre le SGBD il est difficile de proposer des alternatives

et qu'elle est-elle cette SGBD qui fait subir ces désagréments ?

Citation:

---

pour avoir subi des désagréments avec des id auto-incrémentés

---

Sinon, c'est un programme je dirais classique, c'est même un vieux classique des années 80, appelé à l'époque "fusion" ou matching de fichier où les 2,n fichiers (nécessitants d'être triés en ordre selon la même clé) sont lus séquentiellement l'utilisation de la plus petite clé* (je ne me souviens plus du nom exact employé à l'époque) permettant de connaitre l'opération à effectuer (INSERTION/MISE A JOUR).

Je doit encore avoir les schémas de programmation . Oui je parle de schéma car où j'ai appris ces méthodes, au VENEZUELA, c'était plus des schémas que des diagramme de programmation, je n'ai jamais retrouvé ce type de représentation par la suite.

:aie: j'ai l'impression d'être un dinosaure

[edit] *j'ai ré-ouvert mon cahier vénézuélien on y utilisait le terme de "clave menor"

Bonjour,

je parle plutôt de synchronisation dans mon cas et pas de réplication.

J'ai rencontré le problème de l'auto-incrémentation avec des bases nomades, dans des situations sans contact direct avec le serveur distant. Elles sont alors remplies indépendamment de la base principale et regroupées ultérieurement. Il y a des clefs étrangères. En usage quotidien, tu peux, non tu vas, avoir des doublons au moment de la recentralisation. Donc, j'utilise une autre méthode basée sur un stamp complété par une string aléatoire. J'aurais pu utiliser une chaine totalement aléatoire : les risques de problèmes sont nettement moins fréquents qu'avec les clefs auto-incrémentées. La probabilité de doublon est même minime en 24 H. Par contre, pour la réplication entre les 2 serveurs distants que nous possédons, il n'y a pas besoin de Delphi. Le SGDBR est autonome à ce niveau.

Voilà, voilà. Zac.