imam dvije baze podataka. jedna je od web stranice, a druga od programa za prodavace (sales representatives). i jedna i druga baza imaju par tabela (admin, cutomers, sales…) sa istim imenom. dobio sam zadatak da ova dva programa “uguram” pod jedno, tj. da sales i customers tabele budu zajednicke za oba progama.
da bih od ove dvije baze napravio jednu, mislio sam da preimenjem tabele, tj. da web tabelama dodam prefix web_ (web_admin, web_orders,…) a drugim sr_. Zajednicke tabele ne bi imale prefix.
Medjutim, ako preimenujem tabele onda moram i preimenovati svaki query?!?!? Nije to neki veliki posao (sve ide u vojni rok :)), medjutim, bojim se da pri tom ne zaboaravim na neki query il da ne zafrknem nesto?
interesuje me d ali neko ima neku bolju soluciju?
moja “pocetna” ideja je da na drugoj mashini napravim naprvim kopije obe baze i i izmjenim imena a onda pocnem mijenjati kod u programima. A kada sam gotov zamjenim sari kod sa novim a postojecim baze (ne localhost) promjenim imena i sastavim?!?
Nije to bas tako lako mislim ima posla tu Ne znam kako si planirao riješiti ali svaka modifikacija querya može dovesti do problema, ono što je još važnije kasnije kad budeš radio neki upgrade i sl moraš imati u vidu da si dirao te querye.
Za početak komplet backup pa recovery na localhostu i testiraj.
hmm,zasto pod jednu to je previse posla (ma i nije ali,nije ni malo)zasto jednostavno ne linkovati upit dodatnim upitom koja ce voditi do jedne od ciljnih baza.
Zavisno od strukture tabela,Postaj nesto od toga da se vidi nace se rijesenje.
afane - koji su argumenti ZA udruzivanje tih baza podataka? zasto planiras to raditi? Iskreno - razvijam sa nekim ucenicima takodjer jednu aplikaciju i iz sigurnosnih razloga smo webDB i appDB razdvojili. Zasto? pa najobicnije, neko ti moze preko weba doci do sifre za DB i onda mu stoji citava DB na raspolaganju ( i web i ta za aplikaciju ). Posto se ocigledno radi o razlicitim podacima ( znaci neces tabele spajati ), najjednostavnije bi bilo da jednu ili drugu db - dumpnes ( mysqldump ) i generirani file izmjenis tako da se kreiraju tabele sa drugacijim nazivom tj. sa prefixom. Ukoliko je program napisan kako je “Bog rekao” - onda ti queries nisu fixirane tj. imas variable sa imenima tabela i mozes ih lako izmjeniti
Baze su vrlo interesanta stvar. Kod takvih operacija kao sto si ti naveo prvi korak ti je da sredis zajednicke baze. Prvi korak je da identifikujes slogove koji predstavljaju isti entitet u obe tabele i da ih zamjenis s jednim slogom. Naravno odham u takvim situacijama ce doci do toga da ce ti primarni kljucevi biti poremeceni tako da tokom konsolidacije vodis evidenciju o vrijednostima primarnih kljuceva u obe baze. Kada zavrsis konsolidaciju i kada ti je nova table spremna za upotrebu, prije nego je ubacis moras sve strane kljuceve (forign keys) u svim tabelama koje refernciraju zajednicke table updateovatt. To ce ti osigurati referential integrity. kada to zavrsis mozes poceti s preimenovanjem tabela. nako toga kreiraj views koji ce se oslanjati na novu strikturu (nova imena) i onda im fino dodijeli layout koji su koristili u starim bazama. Nakon toga na red dolaze applikacije koje ce sve natjerati da koriste ove view-ove koje si napravio. Na taj nacin ces izbjeci velike promjene u aplikaciji. Jedine promjene ce bit da umjesto dirketne veze na tablu ce se kopcati na view, a za sve query-e nije bitno jer ne prave razliku izmedju tabele i view-a u definiciji ( … FROM table or view … ista stvar) . Mnogo je jednostavnije osigurati stari table layout u view-u nego mijenati cijelu aplikaciju da je skroz prilagodis novom layout-u. Jedino moras voditi racuna da novo kreirani viewo-vi nemaju joins jer u tom slucaju ce biti read-only (no updates, inserts or deletes). Pazljivo planiraj i testiraj sve par puta prije konacnog koraka.
afane - koji su argumenti ZA udruzivanje tih baza podataka? zasto planiras to raditi? Iskreno - razvijam sa nekim ucenicima takodjer jednu aplikaciju i iz sigurnosnih razloga smo webDB i appDB razdvojili. Zasto? pa najobicnije, neko ti moze preko weba doci do sifre za DB i onda mu stoji citava DB na raspolaganju ( i web i ta za aplikaciju ). Posto se ocigledno radi o razlicitim podacima ( znaci neces tabele spajati ), najjednostavnije bi bilo da jednu ili drugu db - dumpnes ( mysqldump ) i generirani file izmjenis tako da se kreiraju tabele sa drugacijim nazivom tj. sa prefixom. Ukoliko je program napisan kako je “Bog rekao” - onda ti queries nisu fixirane tj. imas variable sa imenima tabela i mozes ih lako izmjeniti
Pozdrav
Ice[/quote]
Argumenti? Pa, glavni argument je da izbjegnem konektovanje na vise od jedne baze u istom trenutku. jer, ako kupim podtke iz nekoliko tabela (JOIN) to nekako i mogu “sazvakati”, ,ail da u isto vrijeme su te tabele iz drugih baza - e, nemam vremena za takvo eksperimentisanje. to bi bio glavni razlog.
I, upravo sam tak oi uradio, sa mysql dump-om. Ali, to je bio najlakse korak. Najvise vremena sam potrosio mijenjajuci imena tabela u samom kodu. SRECOM, iako su neke tabele imale ista imena nisu imale istu strukturu tako da sam isao jednostavno od stranice do stranice i koja je bila sa greskom - tu sam mmorao mijenjati imena. Nekad su i “greske” korisne
[quote=IceBreaker]afane jesi htio spojiti sadrzaj dvaju tabela u jednu ili samo dvije baze podataka sa istim imenima tabela?
Pozdrav
Ice[/quote]
dvije baze sa nekoliko tabela cija imena se poklapaju.
no, "odradio sam ovo u medjuvremenu tako sto sam svim tabelama jedne baze dodao prefix web_ i onda uradio isto u kodu. trebalo mi je sat vremena, ali opet nije bilo tako strasno
[quote=Chupo]Baze su vrlo interesanta stvar. Kod takvih operacija kao sto si ti naveo prvi korak ti je da sredis zajednicke baze. Prvi korak je da identifikujes slogove koji predstavljaju isti entitet u obe tabele i da ih zamjenis s jednim slogom. Naravno odham u takvim situacijama ce doci do toga da ce ti primarni kljucevi biti poremeceni tako da tokom konsolidacije vodis evidenciju o vrijednostima primarnih kljuceva u obe baze. Kada zavrsis konsolidaciju i kada ti je nova table spremna za upotrebu, prije nego je ubacis moras sve strane kljuceve (forign keys) u svim tabelama koje refernciraju zajednicke table updateovatt. To ce ti osigurati referential integrity. kada to zavrsis mozes poceti s preimenovanjem tabela. nako toga kreiraj views koji ce se oslanjati na novu strikturu (nova imena) i onda im fino dodijeli layout koji su koristili u starim bazama. Nakon toga na red dolaze applikacije koje ce sve natjerati da koriste ove view-ove koje si napravio. Na taj nacin ces izbjeci velike promjene u aplikaciji. Jedine promjene ce bit da umjesto dirketne veze na tablu ce se kopcati na view, a za sve query-e nije bitno jer ne prave razliku izmedju tabele i view-a u definiciji ( … FROM table or view … ista stvar) . Mnogo je jednostavnije osigurati stari table layout u view-u nego mijenati cijelu aplikaciju da je skroz prilagodis novom layout-u. Jedino moras voditi racuna da novo kreirani viewo-vi nemaju joins jer u tom slucaju ce biti read-only (no updates, inserts or deletes). Pazljivo planiraj i testiraj sve par puta prije konacnog koraka.
Pozdrav
ch[/quote]
Uh?!? Stari moj, od svega ovoga najbolje sam razumio posljednju recenicu - koja je u stvari i najvaznija. Ovo bi pretesko za mene.
ukratko poenta ti je da kada kombinujes tabele moras jako voditi racuna o primarnim kljucevima (obicno ID polja) u tim tabelama. I onda ti sve k’o lavina provuce kroz ostale tabele koje se oslanjaju na ta id polja. zato budi jako oprezan kod kombinovanja tabela.
Afane, konektovanje na dvije baze ne proizvodi apsolutno nikakav gubitak performansi, barem ne na uobičajenim db engines.[/quote]
Cuj?!?
Pravo da ti kazem, nikad nisam imao potrebe da tako nesto radim tako da niti znam nesto o tom slucaju.
Kako bi izgledao query za ovaj jednostavan slucaj:
db1 > tab1 > col11|col12|col13
db2 > tab2 > col21|col11(FK)|col22|col23