Višekorisnička WEB aplikacija - dobra praksa

Zdravo svima,

Imam dilemu oko toga, šta bi bila dobra praksa u projektovanju baze tj. tabela za višekorisničke WEB aplikacije.

Konkretno, da li je za primer gde treba za više korisnika obezbediti da svako od njih ima listu proizvoda koje prodaje (ako je na primer WEB Prodavnica u pitanju), da se sve to stavi u jednu tabelu sa ovakvom strukturom:

Tabela Proizvodi ima sledeće kolone:

Korisnik,
Proizvod,
... (nije bitno na dalje)


To bi značilo da tabela ima slogove:

Korisnik Proizvod

Pera Televizor
Pera Kompjuter
Pera Tastatura
Mika Kompjuter
Mika Monitor


U ovakvom modelu, u svakom baratanju sa podacima, koristio bih uslov da je korisnik = ulogovani korisnik i sa njim radio dalje operacije (select, insert, update...)

Na primer u SQL-u bi to izgledalo ovako:

SELECT * FROM Proizvodi
WHERE Korisnik = 'Pera'
AND Proizvod .... (dalje nije bitno)


Ovako bi uz neki bag u programiranju rizikovao da Mika možda vidi podatke koji su zapravo Perini.

Na MS SQL-u postoji mogućnost da se iste tabele kreiraju pod različitim Shema-ma, pa bi mogao da napravim istu tabelu i za Peru i Miku, ali pod shemama koje se zovu:

Pera.Proizvodi
Mika.Proizvodi

U prvom primeru sa jednom tabelom, naravno podrazumevana je shema DBO, tj.
dbo.Proizvodi.

Model sa različitim Shema-ma mi deluje jako komplikovan.

Zbog toga sam pokrenuo ovo pitanje da vidim šta je dobra praksa i kako se rešavaju ovakvi problemi.

Razlicita schema nema smisla. Sta su ti "proizvodi"? Obicno je "Korisnik" jedna tabela, a sve ostale referenciraju tu tabelu, po njenom primarnom kljucu. Plastican primer: Petra Petrovic promeni prezime, ili Pera vise nije uvoznik nego Laza, ili.... sta god da se desava, nemam pojma sta ti znaci ova tabela "Proizvod". :) Morao bi da na X mesta menjas, sto nije dobar dizajn. :)

Ovo sad, samo za pocetak. Probaj da potrazis sta znaci "normalizacija baza podataka" - i drzi se toga. Ako nemas par hiljada istovremenih konekcija na bazu, ili vise od terabajta u bazi ne postoji nijedan razlog zasto ti normalizovana baza nece biti savrseno resenje. :D

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Nisam lepo objasnio, tj. puno stvari sam podrazumevao a nisam napisao.

Baza je naravno normalizovana, postoje Primary i Foreign Key, ali nisam hteo da opterećujem diskusiju time.
Tabele bi izgledale ovako:

Tabela Korisnici

ID Ime

1 Pera
2 Mika



Tabela Prozvodi

Korisnik Proizvod Cena ...

1 Televizor 100
1 Kompjuter 200
1 Tastatura 10
2 Kompjuter 210
2 Monitor 150


Zamislimo da pravim WEB prodavnicu/platformu za prodaju nekih proizvoda, kao što je AliExpress.
Tu imamo više korisnika (prodavaca) i svako od njih ima neku svoju listu proizova (artikala) koju prodaje kao mini prodavnicu.

Kada bih radio sa ovakvim modelom podataka i hteo da prikažem listu onoga što prodaje Pera, to bi bio upit:

SELECT * FROM Proizvodi
WHERE Korisnik=1
(da ne pišem sada ceo upit sa JOIN da bi to bilo sve lepo, nije to suština).

Ono što me brine je sigurnost podataka tj. da li je dobra praksa ovako držati sve u jednoj tabeli a realno radiš za više korisnika koji su zapravo male prodavnice.

Naravno, ne pravim WEB SHOP ali mi je najlakše na ovom primeru da prikažem ono što me interesuje tj. da vidim da li postoji bolje rešenje od ovoga?



_{[Ovu poruku je menjao aca405 dana 09.03.2020. u 22:48 GMT+1]}

Kada praviš "multitenant" aplikaciju (jedna aplikacija se koristi za više različitih entiteta) uvek se postavlja nekoliko pitanja
1. da li različiti korisnici DELE neke podatke (jedan primer loše aplikacije je da je više korisnika delilo isti kontni plan, jedan doda novi konto, pa svima popada aplikacija)
2. da li postoji zajednička administracija (na primer, ako podeliš sve tabele na više baza ili šema, da li radiš bekap za svaku bazu posebno, ili to sve radiš na jednom mestu)
3. da li radiš neke vrste konsolidacija (recimo, ako su u pitanju više delova istog pravnog lica, pa treba da praviš upite nad bazom nad svim podacima, deljenje podataka u više tabela sa različitim prefiksima ili sufiksima užasno komplikuje upite)
4. pravljenje kompletne šeme za svaki entitet otežava situaciju kada treba da definišeš šifarnike koje treba deliti (a, ako to ne uradiš, tipično dolaziš u situaciju da će bar jedan šifarnik koji je deljen ispasti nedovoljan u nekim slučajevima).
5. pitanje bezbednosti, slabost u aplikaciji znači da će svi klijenti imati kompromitovanu bazu, ako je deljena. Ako nije i dalje može sve da procuri, ali možda imaš sreće.

Ako pravis nesto kao prodavnica, preporuka je uvek EAV .

https://en.wikipedia.org/wiki/...3attribute%E2%80%93value_model

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Sigurnost podataka mi je najveća briga.

Najlakše je sve spakovati u zajedničke tabele i odvajati podatke po korisnicima, kao što sam gore naveo u primeru.

Naravno, ne bih primere poput kontnog plana stavljao u zajedničku šifarnu tabelu jer svaki korisnik može da ima specifičnosti.
Šifarnik poštanskih brojeva bi mogao biti jedinstvena tabela kao i sve ostale tabele koje su propisane od nekog tela i bez mogućnosti promene od strane korisnika.

Od prošle godine je stupio na snagu zakon o zaštiti podataka o ličnosti (poznatiji kao GDPR) pa bi bilo dobro da aplikacije uskladimo sa propisima. Nisam video da GDPR preporučuje neke dobre prakse za Data Model, već se više bavi time koliko se dugo čuvaju podaci (npr. onoliko koliko traje ugovor sa klijentom pa posle se briše), kao i mogućnost da se evidentira ko je sve imao pristup kojim podacima (logovanje) i da se to na zahtev dostavi klijentu.

Razmišljam da podatke o korisnicima držim u posebnoj bazi podataka (princip Identity Servera) pa da tako umanjim mogućnost kompromitovanja podataka.
To naravno komplikuje rešenje, ali to i jeste pitanje, dokle ići a ne preterati tj. da se dobije dovoljan stepen sigurnosti a da dizajn i kasnije održavanje ne bude noćna mora.

Da ne odlutam previše, pozivam sve učesnike da se priključe ovoj temi ako imaju iskustva sa dizajnom "multitenant" aplikacija, pošto još uvek nisam siguran kojim putem krenuti.

Pa kud se baš dede za projektovanje baze, ccc. :) Pa jel' moguće da je baš taj deo posla, onako, NAJBITNIJI od svih ostalih, ukoliko aplikacija, zavisi od baze? ;)
Jeste. I nije sarkazam. Na izgled ne deluje tako, ali, dobro projektovana baza jeste zapravo odvukla (treba da potroši) najviše vremena. Zapravo, u većini slučajeva ispadne tako, ako se radi na nečemu ozbiljnom.

Ja volim sve iz cli interfejsa da radim, međutim, ponekad nije loše opaliti i neki grafički interfejs.

Grafički interfejs ili program tipa -> dbeaver
Ultimativnije (free) rešenje nećeš naći. Mnogo toga može da olakša kroz dijagrame, itd.

Drugi GUI alati u poređenju sa dbeaver-om za sql su mi u potpunosti diletantni.

Potpis

about:networking

@nkrgovic

Pogledaću EAV, hvala. :)

Ima dosta da se čita o tome pa će trebati malo vremena.

Pisao sam prethodni post u isto vreme kada i ti, tako sam kasnije video tvoj post.

Šta da kažem, nekako, kada god nešto novo pravim prvo razmišljam kako to spakovati u tabele (stara škola, teško se menjam :))

Moj problem je što se prvi put srećem sa ovakvom potrebom, jer sam do sada radio uvek aplikacije za "jednu firmu" (da tako kažem), pa nije bilo problema što su podaci u jednoj bazi tj. tabelama.

Eto divnog primera gde možeš žestoko da pogrešiš :)

Kažeš, poštanski brojevi mogu da budu jedna tabela, pa ti onda dođe bosanac, pa kaže - meni ne trebaju poštanski brojevi iz Srbije, samo iz BIH...
Pa ti onda kaže klijent iz Srbije - pa kako da unesem adresu klijenta iz Londona, kada ga nema u šifarniku, a i poštanski broj je kombinacija brojeva i slova.

Pa onda ispadne monstrum od tabele, kada budeš počeo da unosiš poštanske brojeve Burkine Faso ili Vanatua.

Sinoc sam bio premoren....

Uglavnom, naravno da ce aplikacija koja je multi-tennant drzati podatke u jednoj semi, koncept pravljena odvojene seme za svakog tenanta je sumanut. Cilj baze podataka je da drzi podatke, sa pripadajucim relacijama izmedju njih, u formatu koji je pogodan za lako i brzo citanje. Sve dok imas jednu aplikaciju nema smisla da imas vise sema - pre ima smisla da imas vise aplikacija nad jednom.

E sad, sta i kako dalje, zavisi od tebe. Postanski broj moze da se posmatra kao atribut entiteta korisnik, koji ima neki vrednost, pa da i korisnika razbijas u EAV semu. Moze da se smatra nepromenjljivim i da se samo upuca u tabelu korisnika, sto isto nije lose jer se oni ne menjaju bas cesto, a moze i da se izdvoji u posebnu tabelu, ali da - onda imas neka druga ogranicenja. U svakom slucaju tabela postanskih brojeva nece biti monstrum, osim ako tabela korisnik nije monstrum - jer ce imati manje (ili, u granicnom slucaju isto) slogova kao tabela korisnik. Jedino sto mislim da od validacije na nivou baze nema nista, mada i to je OK, validacija na nivou baze ima smisla samo za kriticne podatke.

U svakom slucaju, aplikacija je ta koja mora da obezbedi multi-tenancy, ako pogresis u njoj - pogresio si. Takodje, sistem u kome ces praviti dodatne tabele za svakog korisnika je, po meni, pogresan, bez obzira za sta bila ta tabela. Prvo, jer ces pre pogresiti u tome koju tabelu citas, a drugo jer to ne skalira nikako. Napravi dinamicku semu za sve i koristi je, to da svaki korisnik zbog specificnosti neceg vec (kontni plan, nebitno) ima svoje tabele.... Sta mislis, kako rade veliki ERP sistemi? Mislis da SAP cloud ima tabele za svakog korisnika? :)

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Sve zavisi od toga koliko i kakvih requesta ocekujes u sekundi.
Za teze stvari nikako ne smes golu bazu bez middleware-a da isturis
korisniku iz prostog razloga sto same baze nisu u stanju
da hendluju mnogo reqs/sec.

edit:
pa cak recimo mysql ima mali limit koliko konekcija
moze imati istovremeno. Tu znaci middleware moze
da prihvati i po par hiljada konekcija a onda da serijalizuje
reqs-e prema bazi. To je moja ustaljena praksa i zadnjih
20 godina radi dobro :P

Hvala svima, dopada mi se kako se razvija ova diskusija.

Baza na kojoj radim je MS SQL i ne očekujem veliki broj transakcija u sekundi, tako da bih ostavio po strani diskusiju o performansama.
Inače, imamo slučaj sa velikim brojem transakcija na MS SQL i nemamo problema sa tim.

U međuvremenu sam malo čitao na temu Multitenant aplikacija i došao do toga da postoji više načina izolacije po korisnicima:

1. na noviu tabela, u zajedničkoj bazi, gde se u svim tabelama nalazi kolona za ID korisnika čiji su podaci,
2. na nivou shema - više istih tabela kreiranih sa različitim shemama - svaki korisnik ima svoju shemu
3. na nivou baza - tj. svaki korisnik ima svoju bazu sa svim objektima potrebnim za rad.

Više detalja, može se videti na ovom linku.

Za scenario koji ja razmatram, mislim da mi je je prva varijanta prihvatljiva i da ću ići u tom pravcu razvoj.
Ne planiram da radim specifičnosti tj. da neke tabele menjam samo za neke korisnike već bih držao tabele jednake za sve korisnike, tako da se i tu uklapam u prvi model.

Šifarnik poštanskih mesta mi ne liči na dobar primer gde očekujem da zapne, mada razumem probleme o kojima je pisano.
Mislim da je bolji primer primer sa proizvodima koje recimo prodavnica prodaje, ali i takve stvari iz ugla performansi se mogu poboljšati pravilnim Cluster Index-om po korisniku...

Naravno da će biti slojeva koji će morati da drže biznis logiku i čuvaju konzisetntnost podataka u ovakvom multitenant okruženju, pa mi liči da treba raditi na tome da se umanje rizici greške i kao posledica toga da se podaci kompromituju (u prevodu, puno testiranja :))

Polako se kristališe u kom smeru treba ići pri razvoju ovakvih aplikacija.

Prvo treba predvideti koliko će naša aplikacija imati različitih korisnika. U mom slučaju su to desetine ili stotine. Verovatno neće biti hiljade ili više.

Razdvajanja na novou baza mi liči da bi bilo potrebno za velike firme i primenljivo je održavanje samo za nekoliko takvih klijenata.
Veći broj klijenata bi dovelo u problem rad sa više baza, pa i sa više shema (ova varijanta mi je najmanje primamljiva).

U mom slučaju, gde se broj korsnika meri desetinama ili stotinama, a daleko manje od 100.000, prvi model mi liči kao najprikladniji.

Isto tako, u tom modelu ne vidim ograničenja u dizajnu i ako ih bude 100.000, samo možda treba razmotriti kako poboljšati perfomanse, ali ako dođemo do tog broja, lako ćemo (to su slatke muke) :)

Jedno od resenja moze da bude da u bazi napravis view za svakog korisnika koji mozes da filtriras po zelji.

Ako korisnici nemaju veze jedan sa drugim mislim da bi baza po korisniku vise odgovarala, sa time da se dodavanje korisnika ne vrsi cesto.
Pretpostavljam da kad kazes "korisnik", mislis "klijent", zato sto u drugom slucaju, ukoliko je baza jedna za sve "korisnike" resenje sa tabelama
ima mnogo vise smisla.

"Inače, imamo slučaj sa velikim brojem transakcija na MS SQL i nemamo problema sa tim."

E sad proverih limite, ms sql moze dosta toga, oduvek sam se pitao zbog cega bi to koristio
umesto mysql-a ;)

Osim dobro dizajnirane scheme, kljucno je da se sql queries izvrsavaju brzo i efikasno, jer ako se izvrsavaju sporo i vise njih paralelno u isto vreme, dolazi do povratnog usporenja svih query-ija koji su u toku.
Postoji matematika koliko memorije, koliko CPU cores u f-iji broja konkuretnih queries i prosecnog vremena izvrsavanja tih n upita.

S obzirom da je riječ o SQL Serveru, pogledaj može li ti pomoći Row Level Security (imaš ovdje neki primjer)

Potpis

http://www.dropbox.com/referrals/NTQ0MTI2NDc5
https://www.agronomija.info/
Failure is not an option. It comes bundled with your Microsoft product.