Hvilke rettigheter bør Utviklere har i Dev databaseforekomsten

stemmer
5

... og hvordan skal de tillatelser gis. Jeg jobber i et stort IT-avd med 70 + programmer, noen i SQL server og mest i Oracle. Hvert system har en prod, QA og Dev eksempel. Vi (jeg er en utvikler) har skrivebeskyttet tilgang til prod / QA, som jeg er fint med. I SQL Server utviklings tilfeller devs får db_owner, som fungerer helt fint. Debatten er over hvilke rettigheter jeg skal ha i DEV Oracle-databaser.

Jeg erkjenner at beste fall ville være å ha hver dev kjøre sin egen instans på sin arbeidsstasjon for utvikling, men på grunn av størrelsen på databasene dette ikke har vært ansett som et alternativ.

Jeg er også interessert i hvordan disse tillatelsene skal brukes. I Oracle tillatelser gitt via en rolle ikke er aktiv under PL / SQL henrettelse så roller (selv de dba rolle) er ikke nyttig. Det etterlater ved hjelp av en innebygget i konto (system) eller lage mange brukere accross titalls database og direkte gi en rekke tillatelser til hver. I mitt sinn bare la utviklere innlogging som system gjør mye fornuftig, men våre DBA hevder det er en dårlig idé.

Publisert på 17/09/2009 klokken 22:03
kilden bruker
På andre språk...                            


7 svar

stemmer
3

Vi pleide å bare gi utviklere tilgang til programkonto. Dette fungerer for små butikker, men raskt kommer ut av hånden som antall utviklere øke.

Her er hva vi gjør nå:

  1. Søknaden har sin egen konto (aka skjema).
  2. Utviklere har sine egne kontoer
  3. Data ligger i søknad skjema
  4. Vi har en maur bygge skript for å bygge kode til hva skjemaet du vil.
    • koden omfatter utsikt, pakker, gjenstander etc ..
    • bygge skriptet inkluderer et trinn for å kjøre en lagret prosedyre å gi eksplisitte rettigheter til utviklere til søknaden data
  5. Utviklere gjøre endringer i sitt eget skjema
  6. Når glade de sjekker det inn i subversion
  7. Programmets dev skjemaet er bygget fra den nye undergraving bygge.
  8. Utviklere kan sjekke ut og bygge sine egne miljøer.
  9. DDL endringer på tabellstrukturer er gjort via DBA
    • disse kan brukes skript så vel

Dette har fordelen av at alle grensesnitt programmet er ikke brutt av database utviklere stadig ombygging alt.

Svarte 18/09/2009 kl. 16:42
kilden bruker

stemmer
1

Hvis du utvikler lagret PL / SQL-objekter, da skjemaet eie disse objektene trenger, som du nevnte, eksplisitte tilskudd på objektene brukes. Hvis du har en enkelt 'data' skjema, men utvikler kode i dine egne individuelle skjemaer så bør du få muligheten til å gi tilgang på data skjemaobjekter til utvikling skjemaer. Vanligvis ville jeg forvente brukernavn / passord for dataskjemaet.

I forhold til systemrettigheter (for eksempel CREATE), jeg forventer CREATE TABLE, TYPE, utsikt, PROSEDYRE TRIGGER, synonym. Andre kan være hensiktsmessig (f.eks Context) avhengig av hva du gjør. DBA kan utelukke SKAPE DEBATT som det kan være skadelig hvis mis-bruk. Ditto for privilegier med noen i dem (f.eks SELECT ethvert bord, DELETE ethvert bord)

For ytelse tuning / systemovervåking, på en dev database SELECT_CATALOG_ROLE er bra. Hvis DBA er risikoavers, må du forhandle tilskudd på enkeltvisninger. Gå gjennom referanseguide for din versjon og be om noe du kan bruke.

Svarte 17/09/2009 kl. 23:17
kilden bruker

stemmer
1

Jeg antar at det er et relativt lite antall applikasjons kontoer som eier selve stedene. Så ett eller flere logiske programmer består av tabeller som eies av en bestemt Oracle bruker. Dette ville ikke av system- eller SYS, ville det ikke være noen av de kontoene som Oracle selskapet leverer. Det ville være en konto som din DBA opprettet. Hvis du er kjent med Oracle prøve skjemaer, HR brukeren eier alle bordene i HR-skjemaet som omfatter bakenden for en HR applikasjon.

Starter fra prinsippet om "den enkleste ting som kunne fungere," min første tanke ville være å se om utviklerne kunne logge inn direkte til disse applikasjons kontoer. Dette er ikke den sikreste mulig konfigurasjon, og du åpner opp muligheten for at en utvikler et uhell eller med vilje gjør noen skade som kan være vanskelig å spore eller lett løse. Men det kan fungere rimelig godt avhengig av organisasjonen. Privilege ledelsen trivial-- søknaden eier kontoen allerede har alle de privilegier den trenger mest sannsynlig.

Det neste steget opp ville være å gi alle utviklere et eget skjema til å utvikle seg, antagelig i forbindelse med en belastning på offentlige synonymer i databasen, og et fravær av skjema kvalifiseringer i applikasjonskoden, slik at ethvert objekt opprettet i utviklerens skjemaet automatisk overstyrer felles versjon av dette objektet. Dette gir mye bedre isolasjon. Tillatelser gis i alminnelighet ved enten lage skript som inneholder alle tilskuddene en utvikler behov eller ved å opprette et skript som kopierer alle privilegier fra en "kjent god" kontoen til den nye kontoen. Det er heller ikke spesielt vanskelig å write-- du må bare sørge for at alle utviklerne ender opp med samme sett av privilegier, som vanligvis bare en annen script som kjøres når en ny privilegium er innvilget.

Svarte 17/09/2009 kl. 22:28
kilden bruker

stemmer
0

Jeg erkjenner at beste fall ville være å ha hver dev kjøre sin egen instans på sin arbeidsstasjon for utvikling, men på grunn av størrelsen på databasene dette ikke har vært ansett som et alternativ.

Er det en måte å håndtere dette, kanskje ved å redusere datamengden i dine personlige kopier? Dette virker som en ideell løsning, siden det ville tillate deg å gjøre noen endringer du trenger. Deretter kan du sende dem til DBA når du er klar, og har ham oppdatere felles utvikling server.

Svarte 17/09/2009 kl. 23:17
kilden bruker

stemmer
0

Min gruppe støtter ca 100 apps med ca 20 av dem har sin egen Oracle skjema. Vi har gått nedover veien for alle utviklere har passordet til skjemaet og det er praktisk. Men i ettertid vil jeg anbefale at hver utvikler bruke sin egen Oracle konto for å utvikle. Den viktigste grunnen er revisjon.

Svarte 17/09/2009 kl. 23:09
kilden bruker

stemmer
0

Hvis det er bare en dev eksempel; Jeg vil ha alle brukere har individuelle kontoer lagt til admin rolle. På den måten kan du likevel logge aktivitet på en per-bruker basis; men gi utviklerne nok pusterom til å gjøre sine ting.

Svarte 17/09/2009 kl. 22:17
kilden bruker

stemmer
0

En av DBA arbeidsplasser er å administrere brukerrettigheter. Jeg tror ikke systemet er en god idé for et par grunner, ikke minst er evnen til å slippe en hel skjema som jeg er sikker på at du ikke vil ha. Når det er sagt, tror jeg det er helt greit å gi alt til brukerne og la DBA administrere disse tillatelsene uansett hvor mange titalls kontoer kan det være. De fleste DBA vil ha scripts de kan bruke til å administrere disse tillatelsene uansett.

Lytt til DBA, de vanligvis vet hva de snakker om.

Svarte 17/09/2009 kl. 22:16
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more