Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Konstrukcija baze

[es] :: MySQL :: Konstrukcija baze

Strane: 1 2

[ Pregleda: 3233 | Odgovora: 23 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2315

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+455 Profil

icon Re: Konstrukcija baze29.06.2018. u 09:55 - pre 11 meseci
Tako je @Shadowed. Vodi racuna da ti OAuth omogucava i fine varijante kao npr. "Koliko pojedinacni klijent moze da ima API requests u minutu/satu/danu". Deluje da ti nikad nece trebati dok ti jedan remote klijent ne fasuje neki mallware. ;)

@SAJA: Ako vec hoces samo bearer token, probaj da bude JWT. Jeste, ti si u pravu, ali zivot je laksi svima ostalima kad imaju gotovu biblioteku. Bice i tebi ako se potrudis da je nadjes. Konacno, ako ti ikad iko bude radio audit, imaces problem sa tvojim custom. Ako imas standard, nemas problem.

Takodje, ako imas free servis, sanse da ce neko da ti se nakaci i smara API su JAKO velike ;) Razmisli o rate limitingu po klijentu.

Nemoj da me shvatis pogresno, ja sam odusevljen da neko ko zna BIZNIS procese pravi ERP sistem. Tako i treba da bude i trudim se da ti budem podrska - ali mislim da si resio da izbacis sve sto smatras nebitnim sa biznis strane - i da ce te nesto od toga ujesti kad budes hteo ozbiljno da radis. Pre svega zato sto ljudi koji rade npr. security audit vole standarde - zato toliko potenciram na njima.

Prosao sam jednom, pre X godina, PCI DSS i to tadasnji Tier 4 - i pomalo se secam koliko je bio pain in the....
Please do not feed the Trolls!

Profesionalni sport je oksimoron. Profesionalni sportista je, najcesce, samo moron.
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 2586



+1079 Profil

icon Re: Konstrukcija baze29.06.2018. u 10:15 - pre 11 meseci
Ova diskusija se prilično razvodnila.

Inicijalno pitanje je bilo da li treba fizički razdvojiti baze koje predstavljaju klijentove podatke od podataka za pristup klijentima. A pristup koji je Saja predložio je potpuno pogrešan. Sa stanovišta nekog ko održava bazu sa 10 miliona promena mesečno (a to nije MySql, ali ne vidim neke prepreka da se ne korsisti), koja održava podatke stotina hiljada klijenata mesečno sa desetinama hiljada istovremenih konekcija, jedino što mogu da kažem je da SAJA u startu kreće od nekih nerealnih pretpostavki.

Nema te baze, makar to bio SQLite koja neće brzo vratiti slog kada napraviš upit po primary ili unique key. 95% optimizacije performansi bilo kakve aplikacije koja intenzivno koristi bazu je optimizacija aplikacije (upita), a 5% otpada na tjuniranje i organizaciju baze.

Ono što bih ja razdvojio je deo baze koja se nalazi ispred firewall-a i deo baze koji zahteva kompleksniju zaštitu. Da li svaku fiirmu staviti u posebnu bazu nije bitno. Može biti bitno u smislu nekakvog bekapa i u slučejevim kada firma otkazuje korišćenje usluge. U takvom slučaju realno je pretpostaviti da klijent treba da dobije svoje podatke na neki način. Da li kao export podataka iz baze, što je po meni nepotrebno, ili se za svaki slučaj pravi nekav projekat kroz koji se dogovori format podataka.

Moj predlog, jedna baza kao front end, preko koje se konfiguriše web aplikacija, druga baza koja sadrži finansijske podatke i kojoj se posredno preistupa kroz poseban API.
 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1800
*.dynamic.isp.telekom.rs.



+407 Profil

icon Re: Konstrukcija baze29.06.2018. u 10:43 - pre 11 meseci
Đoko, nisam baš razumeo tvoj predlog. Čini mi se da je upravo i predloženo isto kako i ti predlažeš.
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 2586



+1079 Profil

icon Re: Konstrukcija baze29.06.2018. u 10:53 - pre 11 meseci
Ti si izrazio sumnju da bi faktor zbog kojih želiš da razdvojiš baze nekakvo opterećenje. To je totalno nerealno.
Jedini razlog zbog kojih bi trebalo da razdvojiš baze je zaštita podataka.

Inače, ako ti to nije preterano bitno, jedna jedina instanca MySql servera će da leti.
Da li staviti na poseban server HTTP server, a na poseban MySQL - potupno nebitno. Nikakav problem da razdvojiš, ako zatreba.
 
Odgovor na temu

[es] :: MySQL :: Konstrukcija baze

Strane: 1 2

[ Pregleda: 3233 | Odgovora: 23 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.