Per esperti di db - Replica

[DigitalKiller]

Devo scrivere una semplice applicazione in java che si appoggia su un db mysql. Prima di iniziare a scriverla, però, vorrei sapere da voi se è possibile realizzare una cosa simile. Vi spiego la mia idea...
L'applicazione sarà installata in diversi punti di vendita messi in comunicazione con la sede centrale tramite una vpn. I dati saranno inseriti/letti da entrambi i lati e cambieranno in base ai punti di vendita.
Per diversi motivi (backup dei dati, aggiornamento in tempo reale, possibilità per un pdv di lavorare in off-line in caso di assenza di collegamento) pensavo di installare mysql su tutti i pdv (i pdv lavorerebbero quindi in locale) e, tramite replica, sincronizzare il db con quello della sede centrale. Fin qui, credo, che non ci sia nulla di complicato...
Il problema è questo..
La replica dev'essere attiva in entrambi i sensi, cioè da e verso i pdv. Cerco di spiegarmi meglio.
- il pdv 000001 scarica dalla sede solo i record con chiave uguale a 00001
- il pdv 000002 scarica dalla sede solo i record con chiave uguale a 00002
....
- il pdv 000003 carica sul db della sede i record con chiave uguale a 00003
...

Riassumendo...Nel singolo pdv saranno memorizzati solo i dati di competenza del pdv, mentre la sede centrale memorizzerà i dati di tutti i pdv in un unico db.
E' possibile, quindi, discriminare i record da replicare verso il pdv in base ad un campo (nel mio caso il codice del pdv)? E' sbagliato come approccio? Mysql va bene o devo orientarmi su qualcos'altro?
Spero di essere stato chiaro.
Grazie

[yorkeiser]

Non so se sono un esperto di DB (anzi direi di no), comunque è possibilissimo. Se poi sia giusta o meno come implementazione non sta a me dirlo, dipende dal contesto; sicuramente è più complicata che avere un unico DB in share "permanente", ma a volte ho visto anche soluzioni di questo tipo.
Chiaramente, nelle tabelle in cui tutti i punti vendita possono inserire dati devi prevedere l'esistenza di un campo che permetta di prescindere quale p.v. ha inserito il record. Ad esempio può essere un codice che la singola applicazione java potrebbe leggere ad esempio da chiave di registro, o da un file .ini, o da quel che preferisci.

[DigitalKiller]

Originariamente inviato da yorkeiser

Non so se sono un esperto di DB (anzi direi di no), comunque è possibilissimo. Se poi sia giusta o meno come implementazione non sta a me dirlo, dipende dal contesto; sicuramente è più complicata che avere un unico DB in share "permanente", ma a volte ho visto anche soluzioni di questo tipo.
Chiaramente, nelle tabelle in cui tutti i punti vendita possono inserire dati devi prevedere l'esistenza di un campo che permetta di prescindere quale p.v. ha inserito il record. Ad esempio può essere un codice che la singola applicazione java potrebbe leggere ad esempio da chiave di registro, o da un file .ini, o da quel che preferisci.

Ho analizzato un po' di più il problema..
Non è necessario replicare tutto il db in entrambi i sensi; alcune tabelle verranno replicate solo verso i pdv mentre altre solo verso la sede. In questo modo la cosa si semplifica un po'. Naturalmente pensavo di ricorrere ad una chiave composta dal codice del pdv e da un id unico per pdv. Non sono ancora riuscito a fare dei tentativi, ma non credo ci siano grossi problemi a replicare i dati dai pdv verso la sede centrale in una sola tabella.
Sto provando, senza successo, a replicare una tabella filtrando i record per pdv. Ho provato a replicare una vista, ma non ottengo il risultato sperato.
Una possibile soluzione sarebbero i trigger. Tramite questi, infatti, potrei svuotare e riempire con i record delle tabelle (una per pdv) e poi replicare queste ultime.
Sinceramente non mi sembra una soluzione elegante