Merge vise baza sa identicnom strukturom

Pozdrav,

trebam od podataka iz nekoliko baza napraviti jednu veliku. Sve baze imaju identicnu strukturu, ukljucujuci i:
- 70ak tabela od kojih je 10ak asocijativnih (junction tabela)
- primary key u vecini tabela koji je AUTO INCREMENT
- foreign key koji u vecini slucajeva propagira ON UPDATE CASCADE
- UNIQUE INDEX u vecini tabela, od kojih je u nekim komponovan od vise polja
- innodb storage engine

Glavobolju mi zadaju svi ovi kljucevi. Trazio sam malo i po netu da vidim kakva su iskustva drugih ljudi ali nisam nasao puno (osim da trebam biti pazljiv sa pomenutim relacijama i kljucevima). Najbitnije mi je da su podaci cisti posle merge-a, tj. da nema preklapanja i da se ne desi da neki FK pokazuje na pogresan (ili nepostojeci) slog. Nisam neki DB expert te sam s toga resio da pitam ovde. Ne trazim da neko odradi posao za mene vec da mi da smernice kako pametno i cisto pristupiti u ovom slucaju (ukljucujuci i grubi flow/korake koje treba preduzeti - ako nije previse za iskati :) ) a da ne izgubim nesto bitno iz vida.

Hvala unapred.

nema tu univerzalnog resenja, moras u odnosu na aplikaciju da doneses
odluku sta ces da radis i kako ces to da izvedes, niko ne moze da ti da
resenje sa ovoliko malo informacija koje si dao...

generalna resenja su - u svaku tabelu dodas jedno polje "old_db" i pk
promenis da bude id,old_db umesto samo id (ili sta je vec pk) i onda
samo spucas podadke iz svig baza u jednu samo menjas old_db polje ..
kako ces to posle da citas iz aplikacije zavisi od tebe

druga varijanta je da apendujes datu i reindexiras sve. za to mora
napises app da to odradi

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Hvala Bogdane na brzom odgovoru,

nisam hteo da davim previse sa detaljima zato sto je pitanje vise o pristupu. Jedino sto nisam pomenuo je za cega mi treba ovakvo "pretumbavanje": treba da napravim jednu demo bazu sa realnim podacima koji su prikupljeni (dakle dump-ovi) sa instanci baza od nekoliko musterija (naravno, senzitivni podaci ce biti anonimizirani). U pitanju su telekom operateri tako da je izbor napravljen da sadrzi sto vise razlicitih integracija uredjaja. Sa druge strane nema svaka od musterija sve tipove opreme u svojoj mrezi te ostaje spojiti sve te podatke u jednu bazu da se demonstrira multi-vendor-a solution a pritom zadrzati korektne relacije.

Tako da promene u aplikaciji koja cita podatke nisu pozeljne. Iz tog razloga mi prva varijanta ne doprinosi mnogo, osim mozda kao neki medjukorak.

Na sta trebam obratiti paznju u varijatni apendovanja i reindexiranja?
Da li uopste mogu azurirati PKs koji ce biti propagirani tamo gde su FKs?

za v2 moras da poptuno razumes bazu i da je apendujes "smisleno" dakle

1. ugasis FK

2. odradis append tabele po tabele pritom sto svaki auto number koji
dobijes novi sad moras da updateujes u svim ostalim tabelama gde se
koristi..

3. vratis FK

nije mali posao uopste

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

savetujem da pre cele akcije napišeš par test caseova.

Kapiram. Upravo zato sto nije mali posao a uz to je i "rucni rad" je mogucnost greske uvecana.

Isprobacu vec i sam al ajde da pitam za svaki slucaj - da li je uopste potrebno da ugasim FK? Pricam o ON CASCADE UPDATE - ako dobro razumem: ako FK u tabeli B referencira na PK tabele A onda update vrednosti PKa u tabeli A rezultuje automatskim updateom vrednosti FK-a u tabeli B koji pokazuje na odgovarajuci slog u tabeli A? Ako je ovo slucaj onda samo treba da odstranim AUTO INCREMENT PK-a u tabeli A da bi ovo gore bilo izvodljivo?

U smislu da bih potvrdio da ce (bilo kakav) pristup uopste funkcionisati bez "prljanja" podataka?

moj predlog bi bio da prvo offsetuješ primarne ključeve u pojedinačnim bazama tako da nema preklapanja (morao bi prvo da proračunaš kojoj bazi ide koji opseg za koji ključ), onda možeš praktično da ih appenduješ bez izmene.

- dry run nije preterano bitan obzirom da ubacujes podatke u "praznu"
novu bazu, tako da ako nesto zase1234 drop svega pa ispocetka :D

- nemoj raditi nista rucno, napisi program koji ce to da uradi

- ofset je vise menja ono sa cim ces svakako ici, mozes umesto da "nemas
rupe" da ides sa jablanovom idejom da ofsetujes rucno (tipa prva baza
ide od 0, druga od milion, treca od 2 miliona ....) ... ono sto je tu i
dalje problem su linkovi, dakle "male tabele" ciji id-evi se koriste u
"velikim", fora je sto ti se male tabele verovatno poklapaju (imaju
isti/slican sadrzaj ali razlicite id-ove za razlicite iteme) pa onda tu
mora se pravi neko mapiranje za rekodiranje da ne bi imao duplicirane
male tabele


primer velike tabele je user koji ima user_id, user_type_id, user_name ...

a primer male tabele je user_type koji ima user_type_id, user_type_name,
user_type_permission...

i sad u "bazi 1" imas user_type_id 1 da je "administrator" a
user_type_id 5 je "regular_user" .. a u bazi dva "administrator" je sa
id 7 a "regular user" sa id 11... ti ne treba u "novoj" bazi da imas i 1
i 11 kao admin vec samo jednog admina (1 ili 11) a importovane user
tabele mora da reindexiras tako da za user_type_id koriste 1 ili 11 za
admina (kako si vec resio) ...

malo sam konfuzan al valjda kapiras sta pricam

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ne, već da bi proverio finalnu bazu na kraju, tipa da li se random dobri recordi gađaju, da li ukupno ima onoliko recorda koliko očekuješ itd. Mislim, ne moraš da napišeš formalnu test skriptu (mada, što da ne), već barem da na papiru nabrojiš nekoliko (što više) parametara kojima ćeš koliko-toliko moći da proveriš da nisi negde za*ebo stvar.