mislim da sam ovo vec jednom spominjao, ali “repetitio is mater studiorum”
a vjerujem da neko na kraju moze izvuci nesto pametno iz ove prepiske.
pretpostavimo da imate webstranicu koja nudi neki servis. npr. racunovodstvo automehanicarskim radnjama. pretpostavimo da imate stotinjak klijenata. interesuje me ZA i PROTIV kreiranja jedne baze podataka koja ce imati klijent_ID kao (jedan od) primarni kljuc, ili za svakog klijenta imati posebnu bazu podataka sa identicnim tabelama.
prema pravilima normalizacija, imati dvije tabele iste strukture je pogresno. da li to vazi ako su tabele u razlicitim bazama podataka?
cinjenica je da je pretrazivanje brze u tabelama sa manje rekorda. ali ako se stave sve (identicne) tabele u jednu tabelu i jos uvijek nema vise od 2-3 miliona rekorda sveukupno, onda razlika u brzini ne predstavlja neku veliku prakticnu razliku, jel’ tako?
backup jedne baze sa recimo 60-70 tabela je brzi i vjerujem da zahtjeva manje prostora nego 100 baza i 600-700 tabela?
tacno je da je lakse “eliminisati” jednu cijelu bazu poataka jednom kad klijent prekine ugovor ali isto tako uz jednu malu skriptu elimnisanje rekorda tog klijenta iz zajednicke baze ne predstavlja nikakav veliki posao.
U tvom scenariju pravljenje više baza podataka je nepotrebno jer relacioni sistemi baza su napravljeni upravo zato - da u njih snimaš stvari koje su povezane relacijama (npr. za svakog klijenta imaš unos u jednoj tabeli koji je vezan nekom relacijom, recimo one-to-many, na unose u drugim tabelama). Jedino gdje sam dosad vidio da se upotrebljava više istih baza je za lokalizovane verzije velikih stranica (mada i one dijele zajedničku bazu sa informacijama o korisnicima).
Što se tiče pretraživanja, naravno da je lakše pretraživati nekoliko indeksiranih tabela u bazi nego nekoliko baza sa tim tabelama (čak mislim da je ovaj drugi scenario sporiji jer računaj da se moraš zakačit na svaku bazu pa slat upite svakoj pojedinačno, znači n-baza slijedi n-puta konektovanje+query što već predstavlja napor mašini puno veći nego jedan query). Ako te baš zanima ubrzavanje toga prouči indeksiranje ili (za ekstremne slučajeve) particionisanje baza (što je sad opet priča za sebe).
Što se tiče eliminisanja tog unosa za jednog klijenta (ja pretpostavljam da ti brišeš te podatke a ne čuvaš kao arhivu) postoji metoda i za to, opet relacijama (tzv. foreign keys) kojima postaviš osobinu ON DELETE CASCADE, čime brisanjem unosa u tabeli sa korisnicima automatski se obrišu svi unosi u svim tabelama koji su vezani za tog korisnika.
Za TLDR raju (i sâm sam takav :)): ne, ne treba ti više baza, treba ti jedna ali vrijedna (sa finim relacijama i fino isklesana u SQLu).
Jedino PROTIV koje mi pada na pamet je ako se može desiti da jedan od tih klijenata zatraži zaseban hosting ili ode kod nekoga drugog (a ima pravnih nekih osnova da traži sve svoje podatke).
nisam naveo koja je moja solucija, recimo da budete objektivniji. U svari, ja sam zagovornik jedne baze za sve klijente a tip sa kojim radim je uradio (posto je poceo raditi znatno prije mene) upravo soluciju “svakom klijentu negova baza”. e, ja sad pokusavam dokazati i njemu ali i sefu da to sto jeuradio (izmedju ostalog, jer glavni razlog zbog koje se glodjemo je to sto iako radimo isti “servis” - s tim sto na njegov dio web stranice se logiraju samo klijenti - administratori a moj dio je javni, ecomerce, on nece da “share” bazu podataka nego sve podatke koje ja koristim prvo kopiram na “svoju” bazu podataka pa tek onda koristim. kombinacija ubija. a posto je sefov stari igrac sef vjerje vise njemu neg’ meni.
pretrazivanje se ne vrsi nikada izmedju klijenata. svaki klijent ima pristup samo svoim podacima.
jedino kada dolazi do kkoristenja svih baza odjednom je kada pravimo statistiku za nas same, koliko klijenata, kakav im je ristup, koliko koriste stranice, kolko klijenti imaju svojih klijenata, kolika je narudzba online dnevno/mjesecno/godisnje…
kao sto rekoh, trenutno stanje je"svaki klijent svoja baza" i vjerujem da su izgubljeni klijenti arhivirani kao jedna cjelina.
da je po mome, cijela baza bi bila arhivirana u vidu backup-a a onda klijent koj nas je napustio bio bi izbrisan. a ako bi se bas ukazala potreba onda ne bi bio problem ni arhivirati klijenta zasebno.
da, tacno. ali s obzirom da se gublkjenje klijenta desava rijetko onda to bi bio slab razlog da se koriste multi baze. mislim, vise stete tkom dnevnog koristenja baze nego koristi.
U tome i jeste stvar, ne vidim koristi od pristupa sa više baza ali ne vidim ni neke “štete”. Pravila normalizacije tu nisu dobar argument jer na osnovu IDa klijenta ti izabereš bazu i dalje se svi upiti i ostalo odnose samo na tu bazu. Ne znam da li će vam ikada zatrebati neki sumarni podaci za sve klijente ili pravljenje nekih statistika klijenata? U tom slučaju bi se moralo ići sa jednom bazom.
Za dodavanje novog klijenta moraš svaki put dodavati novu bazu, kopirati šemu sa druge pa postavljati permisije; pisati interface za ovakvo nešto je vrlo škakljivo jer to moraš raditi kao root user tako da je to potencijalna sigurnosna rupa (ako nemaš interface onda se moraš snalaziti ili nekim svojim skriptama ili ručno radit ovu proceduru
Kako određuješ ID klijenta? Sa jednom bazom ne moraš brinuti o tome jer AUTO INCREMENT sam određuje ID klijenta i ne može se desiti da dva klijenta imaju isti ID (teoretski ne može ni u pristupu sa više baza jer ti neće napravit bazu sa istim imenom kao neka druga, no više automatizacije i stavka manje posla :D)
Kako uopšte radite tu dnevnu/mjesečnu statistiku? Praktično morate spojit informacije iz svih tih baza u jednu pa radit na njoj statistiku i tako stalno. Meni se to čini kao nepotreban overhead na serveru + opet spajaš sve u jednu bazu tako da si praktično na istom
Preradit taj sistem koji radi sa više baza da radi sa jednom nije teško ukoliko ubijediš šefa a sigurno ima prednosti nad trenutnim sistemom.
Ja se slažem sa tobom oko pristupa sa jednom bazom (očito :D) no znaš onu izreku koja počinje sa “If it works …”
pa, jedino kada pravimo statistiku svih klijenata za nase vlastite potrebe. koliko je bilo posjeta sveukupno, koliko je bilo narudzbi sveukupno, koliko je svaki klijent “aktivan”… i takve stvari. ali samo za potrebe nase kompanije.
[quote=adioe3]Neki argumenti PROTIV više baza bi bili:
Za dodavanje novog klijenta moraš svaki put dodavati novu bazu, kopirati šemu sa druge pa postavljati permisije; pisati interface za ovakvo nešto je vrlo škakljivo jer to moraš raditi kao root user tako da je to potencijalna sigurnosna rupa (ako nemaš interface onda se moraš snalaziti ili nekim svojim skriptama ili ručno radit ovu proceduru
Kako određuješ ID klijenta? Sa jednom bazom ne moraš brinuti o tome jer AUTO INCREMENT sam određuje ID klijenta i ne može se desiti da dva klijenta imaju isti ID (teoretski ne može ni u pristupu sa više baza jer ti neće napravit bazu sa istim imenom kao neka druga, no više automatizacije i stavka manje posla :D)
Kako uopšte radite tu dnevnu/mjesečnu statistiku? Praktično morate spojit informacije iz svih tih baza u jednu pa radit na njoj statistiku i tako stalno. Meni se to čini kao nepotreban overhead na serveru + opet spajaš sve u jednu bazu tako da si praktično na istom
Preradit taj sistem koji radi sa više baza da radi sa jednom nije teško ukoliko ubijediš šefa a sigurno ima prednosti nad trenutnim sistemom.
Ja se slažem sa tobom oko pristupa sa jednom bazom (očito :D) no znaš onu izreku koja počinje sa “If it works …”[/quote]
ovako i ja razmisljam. osim sto je sefa malo teze (citaj nemoguce) “preraditi”
u svakom slucaju sam dobio odgovor koji sam trazio.
IMa jos jedan argument protiv vise baza. A to je odrzavanje.
Ukoliko budete imali 100 klijenata pa budete trebali npr. promijeniti strukturu baze zbog novih zahtjeva, ili popravljanja necega.
Proces je 100 puta komplikovaniji od jedne baze …
Što se tiče problema kreiranja više baza, koliko sam shvatio baza je identična svaki put… ako je to tačno onda je veoma jednostavno napisati aplikaciju koja će ovo odraditi i postaviti cijelu bazu da bude operativna za par trenutaka.
Recimo uneseš samo ono što je karakteristično za svakog korisnika, usere, premisije itd… i dobijes novu bazu… tako da problem oko kreiranja nove baze oduzima isto vremena kao i unošenje novog korisnika u neku kumulativnu bazu.
Imati jednu bazu ima stvarno nekih prednosti ali ništa što se ne može postići i razdvojenim bazama, ako trebaš agregaciju nekih podataka iz baza onda i za to se može sklopiti skripta, aplikacija itd… koja bi to radila automatski pa bi mogao izvlačiti izvještaje kakve trebaš.
Kako vedran reče korisnik može tražiti nešto specifično, znači samim time ograničavaš svoju fleksibilnost u poslu koja je jako bitna. Zatim šta se dešava kada sve to postane glomazno sa većim brojem klijenata… zvuči mi lakše da jednostavno podijeliš te baze na dva, tri, deset servera kada su odvojene pa onda i bolje iskorištenje resursa jer možeš klijente koji opterećuju servere više od uobičajenog podijeliti na više servera. Zbog svega ovoga mi jedna baza zvuči kao linija manjeg otpora jer bi se u budućnosti to moglo obiti o glavu… a sa malo uloženog truda oko razvoja par skripti i aplikacija zaključujući na osnovu ovdje dostupnih informacija mislim da ti je puno bolje riješenje razdvojene baze.
Ako imaš N korisnika i N baza, pri čemu se spisak tih korisnika nalazi opet u nekoj N+1. bazi, napraviti upit koji će izvuči agregatne podatke za sve korisnike može biti mali problem u najmanju ruku to je onda neka skripta.
S druge strane, profesionalnije zvuči neko clustering rješenje za bazu.
Ako imaš N korisnika i N baza, pri čemu se spisak tih korisnika nalazi opet u nekoj N+1. bazi, napraviti upit koji će izvuči agregatne podatke za sve korisnike može biti mali problem icon_smile u najmanju ruku to je onda neka skripta.[/quote]
Pa šta sam ja rekao…
[quote]listener citat:
ako trebaš agregaciju nekih podataka iz baza onda i za to se može sklopiti skripta, aplikacija itd… koja bi to radila automatski pa bi mogao izvlačiti izvještaje kakve trebaš.
.[/quote]
Cluster ili neko treće riješenje, nisam htio toliko duboko ulaziti u problematiku tog segmenta zbog količine informacija sa kojima raspolažem o tom sistemu.
