SQL pomoč

R

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Alo mojstri SQLa, eno vprasanje: rad bi imel funkcionalnost, kot je "merge replication" pri M$ SQL Serverju ... ampak kot vsak posten balkanec ne bi rad za to placeval gore denarcev, ce ni nujno potrebno.

Ali obstaja kaksna baza, ki deluje preko ODBC in omogoca sinhronizacijo vsebine med razlicnimi racunali, ki niso stalno povezana med seboj, obenem pa ta baza stane toliko, kot M$ SQL Server Express (ki tega ocitno ne podpira) in po moznosti pokuri cimmanj bandwidtha, da sinhronizacijo opravi. Ja, vem da je long shot, ampak mogoce je ze kdaj kdo drug to rabil in pozna kaksen uporaben odgovor
smile-1.gif
 
Utisevalec

Utisevalec

Guru
12. nov 2007
16.161
4.147
113
Sem precej delal na temu problemu in edina rešitev je v programski logiki ne pa v bazah. Tole kar imaš ti opisano zgoraj deluje, ampak imaš na baznem nivoju nastavljene triggerje, ki omogočajo korekciji podatkov. Ok če imaš preposto bazo z enim unikatnim ključem ki je avto incr. ID potem ni panike z integriteto podatkov, ampak ko imaš pa relacije na te ključe ali pa več unikatnih polj si pa lahko (grdo rečeno) s tem rit obrišeš.

Torej tipičen primer, agent na terenu izdaja račun, račun ima zaporedno številko, ki je enaka auto increment IDju (INT). No imaš enega terenca to ni panike, pride domov in se baza sinhronizira, kaj se zgodi ko pa imaš enega v pisarni in enega na terenu, ali pa tri na terenu? Jp, vsi računi imajo enake oznake kar je že davčno/pravno sporno.

Ko pridemo recimo do par nivojskih relacij (ki so vezane na ID, ki je unikatni identifikator) ni šans da restavriraš podatke pa če delaš peš, kaj šele da bo baza sama reševala problem razbite (oz. shizofrenične) integritete.

Skratka edina legalna rešitev je offline mode delovanje in potem prenos na centralno bazo po nekem programskem algoritmu. Recimo prejšnji primer, če imaš 3 ljudi na terenu ima vsak rezerviran lasten interni range IDjev za generiranje vnosov in ko pride do centralne baze se na aplikacijski ravni v glavno bazo vpišejo podatki iz "temporary" baze (kjer vsak podatek dobi svoj pravi zaporedni unikatni ID).
 
D

doto

Fizikalc
25. jul 2007
3.175
0
36
Lahko imaš globalne unique id-je, ki se recimo sestavi iz timestampa in mac addrese mrežne kartice, potem pa nad vsem tem narediš sha256 hash.
 
R

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Tole z unikatnimi IDji je dobra ideja, da se izognes duplikaciji IDjev, ampak sem ravnokar pogruntal, da imam se precej vecjo tezavo. Ne gre namrec samo za dodajanje IDjev, da bi lahko bil problem v duplikaciji, temvec tudi za asinhrono in offline spreminjanje vnosov. Npr. A nekaj vnese, vsi trije sinhronizirajo svoje podatke, potem pa pred naslednjo sinhronizacijo A in C oba nekaj carata nad istim vnosom. Joj bo se glavobolov zaradi tega
cry12bpy.gif
 
S

stein

Fizikalc
16. sep 2007
19.575
1
36
Nekaj takega sem čaral pred nekaj tedni.

Nasvet in nauk zgodbe: Uporabi namensko rešitev !!!!
 
R

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Na kateri si ti pristal (M$ SQL server standard edition ali kaj drugega) ? Klienti so potem lahko na Express (= zastonj) verziji, kakor jaz to razumem.

Cudi me, da za to ne obstaja vec alternativ, saj se tak problem ocitno dokaj pogosto pojavlja (zdaj bo pa tega se vec zaradi razmaha "smart" telefonov in tabel).
 
Utisevalec

Utisevalec

Guru
12. nov 2007
16.161
4.147
113
Citat:
Uporabnik Radirko pravi:
Tole z unikatnimi IDji je dobra ideja, da se izognes duplikaciji IDjev, ampak sem ravnokar pogruntal, da imam se precej vecjo tezavo. Ne gre namrec samo za dodajanje IDjev, da bi lahko bil problem v duplikaciji, temvec tudi za asinhrono in offline spreminjanje vnosov. Npr. A nekaj vnese, vsi trije sinhronizirajo svoje podatke, potem pa pred naslednjo sinhronizacijo A in C oba nekaj carata nad istim vnosom. Joj bo se glavobolov zaradi tega
cry12bpy.gif
Klikni za razširitev

Tudi to je problem, pri več serverjih uporabiš potem polje "timestamp" spremembe in pač tisti ki je zadnji popravlljal se shrani v bazo, drugim se pboriše in na apliakcijski ravni vrne napako. Pri klientih ki nimajo sinhronizacije z atomsko ure greš pa po FIFOtu na podlagi zapisa!
grin1.gif


Pa ja namenske rešitve za to ne obstaja, čisto matematično povedano če gre A v B in C v B in sta A in C različa potem je B lahko samo različen, in če hočeš da ni različen mora ena preslikava izginit.
 
D

doto

Fizikalc
25. jul 2007
3.175
0
36
Jaz bi razmišljal o webservice-ih. V času HSxPA povezljivost mobilnih terminalov ni ravno nek velik problem. Potem pa imaš centralizirano v eni bazi, klienti pa ne shranjujejo lokalnega stanja.
 
R

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Na zalost je delo dobesedno na terenu (lahko tudi v hribih oz. zakotnih ozkih dolinicah), kjer se pogosto zgodi, da signala enostavno ni (niti GPRS/EDGE). Nic mi ne pomaga, ce dela 99% casa, ce najdejo en primer, kjer ne bi delovalo. Potrebno bo pac oklesiti pricakovanja in to razcistiti, pa ne bo nobenih razocaranj..
 
P

Pepe

Guru
20. sep 2007
13.546
5.094
113
Če pogledaš na hitro je pri replikaciji "čista" situacija samo insert. Problem ključev je rešljiv. Mi smo ga reševali s prefiksom. Update/delete po večih lokacijah pa vodi v konflikte, ki jih moraš včasih ročno reševati. Mi smo nekaj časa uporabljali replikacijo na SQL Server 2000. Tam je replikacija generirala trigerje, ki so spremembe pisali v nove tabele. Za potrebe enoličnosti je tabeli dodala guid stolpec, če ga ni bilo. Načeloma je stvar delala, razen včasih (denimo en prenosnik izmed 10-ih enkrat na mesec). Takrat "včasih" pa se je zgodilo kaj tako čudnega, da smo obupali in izdelali svojo rešitev. Sumili smo sicer, da so potniki zaradi "brzine" izklopili prenosnik z mreže enkrat med sinhronizacijo.
Pri tabelah, ki so bile v replikaciji je bil tudi problem nadgradenj oziroma spremembe struktur tabel, ki niso bile tako preproste, kot je to bilo običajno. Kaj točno se je spremenilo do verzije 2008 ne bi vedel.
Po mojem moraš si najprej zadati cilj, katere situacije boš podprl in kaka bo rešitev. In jasno določiti, kaj ne bo šlo. Ker čisto vse pri takem načinu dela ne gre. Mogoče se dobi kak produkt, ki generira tabele in trigerje podobno, kot je to delala original replikacija. Tisto bi delalo tudi na express različici. Ali pa pumpaš podatke križem z Integration Services (aja, tega najbrž zastonj verzija nima) ali denimo svojimi shranjenimi procedurami...
 
R

Radirko

Fizikalc
18. avg 2007
6.242
0
36
Ja, tocno tako bo - oklestiti bo treba pricakovanja, pa ne bo tezav. Tudi sam ne zaupam pretirano takim zadevam, ne le zaradi neukih uporabnikov ampak ker je cisto mozno, da bo povezava (GPRS) padala brez ocitnega razloga. Bo ze nekako, hvala vsem za predloge ! Dobil sem dovolj snovi za razmisljanje.
 
Za odgovor se prijavite ali registrirajte.
Na vrhu Bottom