none
Sincronizzazione database locale e remoto RRS feed

  • Domanda

  • Ciao a tutti, ho sviluppato un'applicazione c# con un database sql 2012.

    il database risiede su un server che si trova nella sede principale e tutti i punti vendita accedono tramite applicazione ai dati. 

    Al fine di migliorare le prestazioni e svincolarmi da eventuali problemi di rete, vorrei mettere un server in ogni punto vendita (3 in tutto) e farli lavorare in locale. I db locali devono ovviamente prendere le modifiche dal server principale ed inviare quelle fatte sul server locale.

    quale è il modo più stabile e semplice per realizzare quello che ho descritto?

    grazie a tutti

    mercoledì 9 aprile 2014 16:02

Risposte

  • Cosa vuol dire essere "pensato" per la andare in replica?

    Un caso più tipico è rappresentato dalle colonne IDENTITY; supponi di avere una tabella con una colonna ID di tipo Integer su cui è stata definita la proprietà IDENTITY, e tale colonna è anche chiave primaria e ci sono anche foreign key che referenziano tale colonna (ad esempio una ipotetica tabella Prodotti con la relativa tabella collegata per le categorie prodotti).

    Se questa tabella viene pubblicata (replica MERGE), potresti trovarti in questa situazione: Il pubblicatore (istanza SQL Server nella sede centrale) inserisce il prodotto con ID uguale a 100, la stessa cosa avviene in uno dei sottoscrittori (punti vendita)... l'agente di replica, in questo caso, inconterà un conflitto durante la sincronizzazione. Questo problema si risolve assegnando "pacchetti di ID" differenti a pubblicatore e sottoscrittori, però bisogna tenerne conto :)

    In questo caso se il DB fosse stato pensato per andare in replica fin da subito, il tipo di dato per la chiave primaria (composta o non) probabilmente stato scelto in modo diverso, magari utilizzando un GUID.

    Ti consiglio di guardare questi due webcast (in Italiano), realizzati un po' di tempo fa da Marcello Poletti, le demo sono state fatte su SQL Server 2005, ma tutti i contenuti sono più che attuali :) ecco i link:

    Ciao!


    Sergio Govoni
    SQL Server MVP
    MVP Profile | Italian Blog | English Blog | Twitter | LinkedIn

    giovedì 10 aprile 2014 08:32
    Moderatore

Tutte le risposte

  • Ciao,

    potresti valutare i servizi di replica di SQL Server pero' il database deve essere "pensato" per andare in replica, solo cosi' potrai limitare i conflitti quando i dati inseriti nei punti vendita torneranno nel database che si trova nella sede principale.

    In realta' quando si parla di sincronizzare i dati, non ci sono soluzioni semplici al netto di aver pensato il DB per la replica fin da subito.

    Un'altra cosa interessante da sapere e' la latenza tollerata dal cliente...

    Ciao


    Sergio Govoni


    mercoledì 9 aprile 2014 16:23
    Moderatore
  • Ciao, grazie per la risposta. Cosa vuol dire essere "pensato" per la andare in replica?

    Mi potresti dare qualche link che mi spieghi bene come implementare la replica del database?

    grazie ancora

    giovedì 10 aprile 2014 07:25
  • Cosa vuol dire essere "pensato" per la andare in replica?

    Un caso più tipico è rappresentato dalle colonne IDENTITY; supponi di avere una tabella con una colonna ID di tipo Integer su cui è stata definita la proprietà IDENTITY, e tale colonna è anche chiave primaria e ci sono anche foreign key che referenziano tale colonna (ad esempio una ipotetica tabella Prodotti con la relativa tabella collegata per le categorie prodotti).

    Se questa tabella viene pubblicata (replica MERGE), potresti trovarti in questa situazione: Il pubblicatore (istanza SQL Server nella sede centrale) inserisce il prodotto con ID uguale a 100, la stessa cosa avviene in uno dei sottoscrittori (punti vendita)... l'agente di replica, in questo caso, inconterà un conflitto durante la sincronizzazione. Questo problema si risolve assegnando "pacchetti di ID" differenti a pubblicatore e sottoscrittori, però bisogna tenerne conto :)

    In questo caso se il DB fosse stato pensato per andare in replica fin da subito, il tipo di dato per la chiave primaria (composta o non) probabilmente stato scelto in modo diverso, magari utilizzando un GUID.

    Ti consiglio di guardare questi due webcast (in Italiano), realizzati un po' di tempo fa da Marcello Poletti, le demo sono state fatte su SQL Server 2005, ma tutti i contenuti sono più che attuali :) ecco i link:

    Ciao!


    Sergio Govoni
    SQL Server MVP
    MVP Profile | Italian Blog | English Blog | Twitter | LinkedIn

    giovedì 10 aprile 2014 08:32
    Moderatore