aplikacija=schema

Schema=User koji posjeduje objekte u bazi.

User koji posjeduje neke objekte u bazi može raspolagati tim objektima bez ikakvih ograničenja (jer ih je on kreirao), takodje taj user može grantovati pristup svim ili samo nekim objektima nekom drugom user-u.

Kada se kreira neki korisnički nalog na bazi to se naziva kreiranje user-a, a kada taj user kreira (ako mu je to dozvoljeno) neki objekat u bazi on postaje schema.

Ne moraju svi korisnici na bazi posjedovati objekte.

Na ovaj način je osigurana sigurnost podataka svih korisnika na bazi.

E pa lepo, ali kada kreiras korisnika na bazi? Bas to me zanima, koji je motiv uvodjenja sheme? To sto on moze da krerira objekte, to mu ne daje smisao...
Hajde da konkretizujemo ovo za potrebe jedne poslovne aplikacije... Ako je kako kaze selector, onda je aplikacija jednako shema? Eventualno ako treba nekome obezbediti neki drugaciji nivo pristupa, npr ako postoji razmena sa drugom aplikacijom, nije lose napraviti neku interface shemu... To je onda drugacija logika od pravljenja shema po korisnicima...

Ne znam koje aplikacije radis ili ces da radis, ali stvar je recimo jednostavna, a odlicno radi.

Kod poslovnih aplikacija tipa finansijsko, robno gde su podaci u okviru poslovne godine onda kreiras usera g07, g08, g09 koji ima set tabela za tu godinu. A realni useri su mika, per, zika itd. Onda jednostavno user g08 daje dozvolu ovim realnim userima. Kad se promeni godina, otvori se user g09 i realnim userima dodeljuju dozvole na ovim novim tabelama.

Ovako programi ostaju isti, i lako se prelazi na sledecu poslovnu godinu. Kad treba da se pogleda neka prethodna onda se prijavis kao g07, g08 i slicno.

Mada nisam siguran da si na ovo mislio.

Jesam, mislio sam bas na tako nesto, kako u jednoj "realnoj" aplikaciji organizovati seme...
Mi koristimo drugaciji pristup: jedna administrativna sema, gde se nalaze opsti podaci koji ne zavise od godine, jedna "stara" sema, za sve prethodne godine i jedna tekuca... I pritom nemamo seme za korisnike, vec sopstveni sistem za autorizaciju...
Mada mi se svidja ideja da postoje seme za konkretne korisnike koji imaju samo sinonime i grantove, bez sopstvenih objekata, mozda samo neki logovi ili slicno. Mada ne znam kako bi se to ponasalo kada ima nekoliko stotina korisnika... Mislim, to treba odrzavati i sve... Mozda razviti to po nekim tipovima poslova, odnosno po nivoima pristupa, pa u okviru toga interne korisnike?

Kako postaviti usere i sheme je jedno od osnovnih pitanja arhitekture jedne DB.
Tj kad se radi idejni projekt ( datamodel) onda se razmisli sta i kako.
Moje iskustvo kod aplikacionih DB-s je da su korisnicki-Useri uvek dobri zbog pristupa aplikacionim-userima. Da li ce oni na kraju praviti svoje objekte ili nece je nebitno u toj situaciji ( bitno je da ne mogu da pokvare objekte koji pripadaju aplikaciji)
Da li ces raditi aplikacija=shema ili ces to razbiti na sitnije delove to je tema za arhitektu.
Ja se zadnjih godina krecem u Datawarehouse i tamo obicno imas za ETL Procese nesto kao
Inkoming User ( Interface prema Sorce)
Staging Shema( NEobradjeni podatci )
Cleansing Shema ili Core Shema ( mesto gde se rade agregati i prociscavanje u stvari glavno radno mesto)
Outgoing ( Interface prema Datamart ili Cube ili Reporting ili...)
U principu se kreiranje shema svodi na ideju sta hoces da radis.
A nakon par godina rada se uvek shvati da pocetna ideja vise nije dobra pa se radi iz pocetka
Kako bi mi inace zaradjivali nas hleb svagdasnji ?
pozdrav
Branko

Šeme su divna stvar. Najbolje je napraviti šemu s nekim generičkim (aplikativnim) imenom i tu staviti tabele i sve ostale neophodne objekte baze. Onda napraviti odgovarajuće role i njima grantovati minimalne privilegije, pa nakon toga u potpunosti zatvoriti šemu tj. tom useru koji je vlasnik šeme ukinuti connect privilegiju. Onda stvarnim korisnicima, koliko god da ih ima, dodeljivati samo odgovarajuće role.

Koncepti bezbednosti i fleksibilnosti koje sve ostale baze samo sanjaju.

Pozz i uživaj u mogućnostima Oracle-a ne odriči ih se