[RDBMS] Owner gebruiken voor onderscheid van secties

[Verwijderd]

Ik zit te denken om de owner te ge(mis)bruiken voor om gerelateerde zaken te groeperen, binnen een database (ga even uit van SQL Server).

Wat bedoel ik hier mee? Nu laat ik de naam van een table, view, sp, etc. beginnen met een afkorting van de sectie waar het overgaat, bijv:
- dbo.HRCustomers
- dbo.spHRAddCustomer
- dbo.LOGRequests
- dbo.spLOGAddRequest
- etc.

(HR staat dan voor alles wat met 'human resource' geralteerd is en LOG voor alles met logging gerelateerd.)

Mijn voorstel is om de owner hiervoor te gebruiken, dus:
- HR.Customers
- HR.spAddAddCustomer (of HumanResource.Customer)
- Log.Requests
- Log.spAddRequest
- etc.

Hoe denken jullie hierover? Zijn er mogelijke problemen als ik hiervoor kies? Ben trouwens ook wel benieuwd wat voor 'naming guidelines' jullie in de database gebruiken (en vooral waarom).

[ Voor 7% gewijzigd door Verwijderd op 15-01-2006 11:19 ]

[Verwijderd]

Nog van niemand een reactie gehad . Is mij vraag onduidelijk of zien jullie hier geen problemen in? .

Ik wil dus ipv dbo, bijv Sales, Facturatie gebruiken om samenhangende tabelen, sp en functies te groeperen (ipv dit in de naam te doen).

[RedRose]

Doe maar gewoon niet, tenzij HR en Log etc echte owners zijn van die databases, wat ik me niet echt kan voorstellen? Je zegt zelf al dat je iets misbruikt en het lijkt me daarom handig dat je MSDN even leest hoe het zit met ownerships e.d.

MSDN Link <-- staat alle informatie in.

verdere info:

[rml][ alg] Descriptive naming - lastig![/rml]

Al naar gelang je smaak zou je ze bijvoorbeeld zo kunnen noemen:

- HR.Customers => HR_Customers, CustomersHR, Customers
- Log.Requests => RequestLog, Request_Log, Log_Request

En dan je Stored procedures gewoon zo benoemen:

- Log_AddRequest , AddRequest, AddEntry, AddLogEntry (etc...)
- HR_AddCustomer, AddCustomer, Customer_Add (etc..)

Hoe het wel eenduidig natuurlijk

Deze is misschien ook wel handig voor je: Over SQL-Server 2000

[ Voor 10% gewijzigd door RedRose op 14-01-2006 12:06 ]

[ripexx]

Waarom wil je dit? Is het noodzakelijk dat je hiervoor aparte DB users hebt. Want alles staat in een schema/database, kan je de schema's dan niet splitsen of gaat het om een "applicatie" waarin je voor de "show" netjes je verschillende objecten wil ordenen. Want in het laatste geval moet je gewoon een consistente naamgeving gebruiken. Eventueel dus met een prefix.

Verder gebruikte ik voorheen een hele slechte naamgeving. Engels gemixed met Nederlands, meervoud en enkelvoud etc etc. Dit kan je voorkomen door vooraf wat langer na te denken over je model en pas later allemaal tabellen te gaan aanmaken.

[Verwijderd]

RedRose schreef op zaterdag 14 januari 2006 @ 12:01:
Doe maar gewoon niet, tenzij HR en Log etc echte owners zijn van die databases, wat ik me niet echt kan voorstellen? Je zegt zelf al dat je iets misbruikt en het lijkt me daarom handig dat je MSDN even leest hoe het zit met ownerships e.d.

Laat ik eerst even duidelijk maken dat ik DBA'er ben en behoorlijk wat over SQL Server weet (althans dat denk ik ). Doe maar gewoon niet vind ik geen sterk argument om het niet te gebruiken. Ik ben op zoek naar mogelijke problemen\ervaringen als ik de owner hiervoor ge(mis)bruik. We gebruiken nu de owner nauwelijks (één externe partij repliceert nu zijn tabellen bij ons), maar typen wel elke keer dbo.

ripexx schreef op zaterdag 14 januari 2006 @ 12:03:
Waarom wil je dit? Is het noodzakelijk dat je hiervoor aparte DB users hebt. Want alles staat in een schema/database, kan je de schema's dan niet splitsen of gaat het om een "applicatie" waarin je voor de "show" netjes je verschillende objecten wil ordenen. Want in het laatste geval moet je gewoon een consistente naamgeving gebruiken. Eventueel dus met een prefix.

Het gaat inderdaad om het laatste geval. Wij gebruiken nu consistente naamgeving (zoals in mijn eerste post te zien) met een prefix, maar ik ben aan het kijken of ik hiervoor niet veel beter de owner kan gebruiken als prefix.

De nadelen die ik nu kan bedenken zijn:
- Het zou kunnen voorkomen dat twee tabellen dezelfde naam hebben, maar alleen van owner verschillen. Dit zou problemen kunnen opleveren, maar als je consequent de owner ervoor zet zou dit geen gevaar moeten zijn.
- Bij het opnieuw opbouwen van de database-server (na een crash bijv.) zou je elke keer all owners moeten toevoegen. Zie ik niet echt als een probleem, maar meer als een extra stap.

[Gé Brander]

Er is geen enkel probleem mee. De schema's zijn daar toch juist voor bedoeld? Je kan dan zonder problemen rechten in 1 keer uitdelen naar alles wat binnen 1 schema hoort. Je kan als HR dus alleen maar bij de HR tabellen en andere objecten. Bij de andere objecten kan je niet komen. Het is een security mechanisme die wel vaker toegepast wordt.

Je kan alleen in situaties belanden waarbij de klant dit liever niet heeft omdat er verschillende beheer uitgangspunten kunnen zijn die dbo als prefix verwachten voor alle objecten. Maar als je het alleen binnen je organisatie gebruikte en niet verkoopt dan kan je je eigen beheer bepalen.

[RedRose]

c70070540 schreef op maandag 16 januari 2006 @ 11:13:
Er is geen enkel probleem mee. De schema's zijn daar toch juist voor bedoeld? Je kan dan zonder problemen rechten in 1 keer uitdelen naar alles wat binnen 1 schema hoort. Je kan als HR dus alleen maar bij de HR tabellen en andere objecten. Bij de andere objecten kan je niet komen. Het is een security mechanisme die wel vaker toegepast wordt.

Je kan alleen in situaties belanden waarbij de klant dit liever niet heeft omdat er verschillende beheer uitgangspunten kunnen zijn die dbo als prefix verwachten voor alle objecten. Maar als je het alleen binnen je organisatie gebruikte en niet verkoopt dan kan je je eigen beheer bepalen.

Een security mechanisme gebruiken waar het voor bedoeld is en daarom security principals als HR etc gebruiken, daar is ook niks mis mee, zoals ik al probeerde aan te geven in mijn eerste post. Het zal wel te puristisch van mij zijn om dan dat te misbruiken puur om databases te ordenen.

Dat je DBA bent is verder ook geen inhoudelijk argument voor mij om mij te overtuigen dat je daarom dan dus wel de owner kan misbruiken.

[Verwijderd]

Het is niet alleen om de database voor het oog te orderen. Het heeft ook als functie om de 'kern'-tabellen (de reden waarom de database bestaat) te scheiden van de 'ondersteunende'-tabellen (zoals Logs, import, export, afdelinggerelateerd, etc.).

Meestal heeft de programmeur enkel toegang tot de kerntabellen, sp's en functies nodig om met de database te werken. De overige tabellen, sp's en functies zijn dan alleen maar 'ruis' en mag hij zelfs niet aanpassen.

En ander functie is om bijv. duidelijk te maken welke sp's alleen intern aangeroepen mogen worden en welke als extern API gelden.

RedRose schreef op maandag 16 januari 2006 @ 11:37:
Dat je DBA bent is verder ook geen inhoudelijk argument voor mij om mij te overtuigen dat je daarom dan dus wel de owner kan misbruiken.

Dat bedoelde ik er niet mee . Ik zei dit alleen, omdat je links naar SQL Server plaatste, maar die heb ik al doorgenomen als DBA. Ik zei het dus alleen om aan te geven waar mij kennisnivo is . Als dit anders overkwam, dan was dit niet mijn bedoeling.

[Gé Brander]

RedRose schreef op maandag 16 januari 2006 @ 11:37:
[...]Een security mechanisme gebruiken waar het voor bedoeld is en daarom security principals als HR etc gebruiken, daar is ook niks mis mee, zoals ik al probeerde aan te geven in mijn eerste post. Het zal wel te puristisch van mij zijn om dan dat te misbruiken puur om databases te ordenen.

Maar dat is toch ook een soort van ordenen? Alleen op security nivo. Dat je er vanuit je applicatie dus gebruik van kan maken is mooi meegenomen.

Dat je DBA bent is verder ook geen inhoudelijk argument voor mij om mij te overtuigen dat je daarom dan dus wel de owner kan misbruiken.

Ik betwijfel of je dit op mij gericht hebt, maar ala.
Ik ben echter wel van mening, dat dit niet echt misbruiken is. Maar daar kan ik naast zitten natuurlijk.

[Gé Brander]

Verwijderd schreef op maandag 16 januari 2006 @ 12:00:
Het is niet alleen om de database voor het oog te orderen. Het heeft ook als functie om de 'kern'-tabellen (de reden waarom de database bestaat) te scheiden van de 'ondersteunende'-tabellen (zoals Logs, import, export, afdelinggerelateerd, etc.).

Meestal heeft de programmeur enkel toegang tot de kerntabellen, sp's en functies nodig om met de database te werken. De overige tabellen, sp's en functies zijn dan alleen maar 'ruis' en mag hij zelfs niet aanpassen.

Dus toch ook een ordening vanwege security?

En ander functie is om bijv. duidelijk te maken welke sp's alleen intern aangeroepen mogen worden en welke als extern API gelden.

[RedRose]

Verwijderd schreef op maandag 16 januari 2006 @ 12:00:
Het is niet alleen om de database voor het oog te orderen. Het heeft ook als functie om de 'kern'-tabellen (de reden waarom de database bestaat) te scheiden van de 'ondersteunende'-tabellen (zoals Logs, import, export, afdelinggerelateerd, etc.).

Meestal heeft de programmeur enkel toegang tot de kerntabellen, sp's en functies nodig om met de database te werken. De overige tabellen, sp's en functies zijn dan alleen maar 'ruis' en mag hij zelfs niet aanpassen.

En ander functie is om bijv. duidelijk te maken welke sp's alleen intern aangeroepen mogen worden en welke als extern API gelden.

Zoals je het nu omschrijft, is het juist geen misbruik, maar juist een aan te bevelen werkwijze. Op deze manier kan je namelijk ook de applicatie zelf specifiek toegang geven tot die databases waar zij bij moeten kunnen. Daarnaast is dat voor schaalbaarheid ook wat handiger. Stel je hebt een (hypotetisch uiteraard) enorme logging I/O. Dan kan je die database, met die aparte owner naar een andere server migreren, zonder dat je daarmee een useraccount migreert die op die nieuwe bak eigenlijk helemaal niet thuishoort.

Dat bedoelde ik er niet mee . Ik zei dit alleen, omdat je links naar SQL Server plaatste, maar die heb ik al doorgenomen als DBA. Ik zei het dus alleen om aan te geven waar mij kennisnivo is . Als dit anders overkwam, dan was dit niet mijn bedoeling.

Ok.

c70070540 schreef op maandag 16 januari 2006 @ 12:26:
[...]

Maar dat is toch ook een soort van ordenen? Alleen op security nivo. Dat je er vanuit je applicatie dus gebruik van kan maken is mooi meegenomen.

Security is er volgens mij niet om te ordenen, maar juist om op controleerbare en configureerbare en overzichtelijke basis dingen dicht te timmeren of open te zetten. Dat daarbij een ordening ontstaat, is mooi meegenomen, in dit geval. Een analogie met bijvoorbeeld LDAP, of Active Directory is dat je users indeelt in groepen (containers, OU's). Je hebt dan een ordening nodig, maar dan alleen als de combinatie logische indeling + het zetten van privileges per OU waar is. Ik miste eerst in bovenstaand verhaal het privilege gedeelte.

Ik betwijfel of je dit op mij gericht hebt, maar ala.
Ik ben echter wel van mening, dat dit niet echt misbruiken is. Maar daar kan ik naast zitten natuurlijk.

Dit was verder niet speciaal op jou gericht nee.