Szinkron 2 adatbázis között
2013-01-03T17:23:03+01:00
2013-01-09T19:45:50+01:00
2022-07-23T17:16:16+02:00
  • 4000 sor az lófütyi.

    40000 már bajosabb lehet, de az sem valami vészes.
    Nemrég exportáltam egy 10 gigásat és az is lefutott ~1 óra alatt.
    Mutasd a teljes hozzászólást!
  • Bocsi, de az implementálás és a kipróbálás között van némi különbség..
    Mutasd a teljes hozzászólást!
  • Nem. Azt a módszert implementálnám, amit javasoltok.
    Mutasd a teljes hozzászólást!
  • Elég hatásos ez egy 4000 soros ID-nél?


    Bocsi, de kipróbáltad?
    Mutasd a teljes hozzászólást!
  • Update-t értem, nézem a két dátumot.

    Insertnél küldjem el táblánként A-nak, hogy B táblájában milyen ID-k vannak, és azokat adom vissza B-nek, melyek ID-je nincs benne a küldött ID listában? Elég hatásos ez egy 4000 soros ID-nél?
    Mutasd a teljes hozzászólást!
  • Ha az SQL Server verziód legalább 2008-as, akkor a Change Tracking nyerő lehet. Kicsit utána kell járni, hogy mi fán terem, de nagyon megéri.
    Mutasd a teljes hozzászólást!
  • OK, már ezt is tudom.
    Nem szoktam MSSQL adatbázist tervezni, csak felhasználom olykor a másokét

    Mindenesetre igen, az általam írt 1. esetben a timestamp helyetti bigint módszert valósították meg a MS-os fiúk is, automatikusan.

    Kösz az infót
    Mutasd a teljes hozzászólást!
  • Az MS-SQL adatbázisban azokra a táblákra amelyek érintettek egy triggert raksz, ami eltárolja, hogy az adott tételen módosítás történt.

    Bocsi, de szvsz felesleges.

    SQL Server 2008 R2 - rowversion (Transact-SQL)
    Is a data type that exposes automatically generated, unique binary numbers within a database. rowversion is generally used as a mechanism for version-stamping table rows. The storage size is 8 bytes. The rowversion data type is just an incrementing number and does not preserve a date or a time.
    .
    .
    Each database has a counter that is incremented for each insert or update operation that is performed on a table that contains a rowversion column within the database. This counter is the database rowversion.
    Mutasd a teljes hozzászólást!
  • Szerintem:

    1. alap eljárás
    B adatbázisban (vagy a szinkronizációt végző program konfigjában) elmented az utolsó szinkron időpontját.
    Minden táblára teszel update triggert ami módosítja a saját lastchanged mezőjét. Ugyan ezen mező default-ja GETDATE().
    A szinkron eljárásban lekéred A azon rekordjait, melyeknek dátuma későbbi, mint az utolsó szinkroné.
    PK alapján megnézed, hogy létezik-e az adott rekord adott B-ben. Ha nem, akkor insert, egyébként update.
    Törlésre én csak logikai törlést használnék a helyedben. Néha esetleg karban lehet tartani az adatbázisokat és a nagyon régen törölt rekordokat ki lehet takarítani.

    2. sql-ek gyártása
    csinálsz egy táblát, amibe triggerekkel elmented a dátumot és a módosításhoz szükséges SQL utasítást. Ez lehet insert, update vagy akár delete is. A szinkron programmal ezeket össze lehet fűzni adott dátumtól és végre lehet hajtani egyben.
    Hátránya, hogy ha többször módosítanak egy rekordot egy nap, akkor az több utasítás lesz, de ennyi szerintem belefér. Itt lehet viszont fizikailag is törölni.
    Mutasd a teljes hozzászólást!
  • Kötözködnek ezek mi?

    Az MS-SQL adatbázisban azokra a táblákra amelyek érintettek egy triggert raksz, ami eltárolja, hogy az adott tételen módosítás történt.

    Az, hogy a tárolásnak milyen a technikája, az leginkább attól függ, hogy hány a tábla, mekkora része az adattételeknek, ami módosul stb.

    Két fő irány van.
    1./ a tételben tárolod el, hpogy ez módosult. Tipikusan "utolsó módosulás timestamp". Innen tudhatod, mely tételek módosultak az utolsó szinkronizálás óta (hiszen annak a timestampjét ismered).
    Én mondjuk nem szeretem a timestamp-t, mert az óra állítható. Én egy bigintet használok erre, ami az egész adatbázisra uniq. (Firebird és sequence). Ez biztonságosabb szerintem, de az elv teljesen azonos. Meddig van kész a szinkronizáció, és ami utánna jön azt szinkronizálni kell.
    Ennek a módszernek a hátránya, hogy szinkronizációkor végig kell olvasnod az egész táblát, vagy indexet teszel a módosulás jelzőre.
    2./ ha kevés tétel érintett, akkor jobban járhatsz, ha a triggerben eltárolod egy erre szolgáló táblába a módosult tábla azonosítóját és a módoult tétel PK kulcsát.

    Innen már csak technikai meló kiolvasni mik módosultak és a módosításokat szétteríteni az sqlite-kra és ha a másik gépeken végrehajtódtak, akkor adminisztrálni, hogy ez is megvan. [mintegy kétfázisú commit]

    Ha minden szinkronban megy és nincs online elérésed az sqlite gépekre, akkor én azt tenném, hogy minden szinkronizálás tulajdonképpen csak egy szép nagy SQL filet hozna létre (az sqlite-knak szánt parancsokkal), amit átküldenék a gépekre és az ottani programok lefuttatnák azt. [mintegy benyomom a queue-ba és majd lesz vele valami]
    Mutasd a teljes hozzászólást!
  • Tehát : "A-rol mindegyik B-re kulon-kulon?"


    Ha ez a valasz akart lenni, akkor mit bonyolit a tobb B..?
    Mutasd a teljes hozzászólást!
  • Az A adatbázist tartják naprakészen, majd az adatokat (pl: reggelente) le kell küldeni a sok B adatbázisnak. Ott csak dolgoznak az adatokkal, de vissza az A-nak nem megy módosítás.

    Tehát : "A-rol mindegyik B-re kulon-kulon?"

    A szerveren MS SQL van a B-k pedig SQLite adatbázisok.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • B-n nem lehet modositani az adatokat? Ha igen, akkor az A-rol erkezo, utolso szinkronizalas ota vegzett modositasok felulirjak a B-n azota vegzett modositasokat?

    Egy db B esetén működik, de most több B között kellene megoldani a szinkronizációt.


    B -> B?! Vagy A-rol mindegyik B-re kulon-kulon?
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Mi az általános technikája két adatbázis szinkronizálásának?
    Mindig csak 1 irányba kellene. A-ból B-be.

    Módosított adatok esetében lekérem A-ból azon rekordokat, melyek [udpdated] dátum mezője korábbi, mint a B [lastsinkronised] dátuma.
    Ez nem mező, hanem a B-re jellemző utolsó szinkronizálás dátuma.

    De új rekordok esetén hogy csinálom? A-n újonnan felvett rekordjaiban van a [new] mező. Egy db B esetén működik, de most több B között kellene megoldani a szinkronizációt.
    Mutasd a teljes hozzászólást!
Címkék
abcd