[MSSQL] views, udf en triggers

[Webby_143]

In mijn applicatie hebben alle hoofdtabellen beperkte rechten voor users. Over al die tabellen zijn views gemaakt waar rechten aan verbonden zitten afhankelijk van hun login. Volgens MS is dit een goed model. Nu is er 1 view waarin ik in de results een extra veld wil tonen dmv. enkele berekeningen. Ik heb hiervoor een UDF gemaakt welke in de select van de view staat als dbo.udf_naam. Het probleem is dat ik nu deze view niet meer kan gebruiken voor insert statements. Ik heb al geprobeerd info te vinden om dit te verhelpen dmv. instead of triggers, maar die geven alleen info over joined queries in views en calculated views. niet hoe je een workaround kan maken voor een extra veld welke bijv. Date terug geeft. Iemand enig idee hoe ik dit kan doen?

[P_de_B]

Misschien wordt dit systeem door MS aangeraden, persoonlijk hou ik er niet zo van. Views moet je gebruiken waar ze voor bedoeld zijn; bepaalde data wel of juist niet tonen aan een specifieke gebruiker. Je laat bijvoorbeeld de kolom salaris uit de personeelstabel niet zien aan bepaalde mensen. Daar kun je goed een view voor gebruiken. Of mensen mogen alleen informatie zien voor reeds gereedgemelde projecten, ik noem maar wat. Maar om nu ook de insert op de view te gaan doen vind ik vreemd. Waarom insert je niet gewoon in de tabel? Je kunt select en insert rechten apart instellen.

[whoami]

Je kan toch gewoon een instead of trigger gebruiken ?
Die code in een instead of trigger wordt gewoon uitgevoerd ipv een gewoon INSERT commando. Je kan dus in die INSTEAD OF trigger de code schrijven die een record in jouw tabel insert als je een INSERT doet op die View.
Het concept blijft toch hetzelfde met een instead of trigger mbt joined tables ?

Verder ben ik het wel eens met P_de_B ivm de INSERT op de tabel zelf.

[Webby_143]

Ik heb me nu al even beter ingelezen op instead of triggers. Wat ik me alleen afvraag is of je daar ook rechten op kan zetten oid. Want als ik die trigger de hoofdtabel laat updaten, maar alleen de sa daar rechten voor heeft zou het fout kunnen gaan?

[whoami]

Die trigger zal wel rekening houden met de security settings van de user die het uitvoert.
Je plaatst de rechten op de 'hoofdtabel', en als de user niet 'sa' is, dan zal het spul niet marcheren.

Probeer het ff uit zou ik zeggen.

[P_de_B]

Instead of triggers zijn wel erg zwaar, ik zou er niet voor kiezen in dit geval hoor. In mijn ogen moet je die alleen voor complexe situaties gebruiken, en moet je in dit geval gewoon in de tabel inserten.

[Webby_143]

Het is nog net een beetje over my head materie, maar ik heb nu een trigger gemaakt (ik wil toch dat views / security model aanhouden en de applcatie bouwt zijn vensters op aan de hand van de inhoud van die views, we gebruiken ze ook voor verschillende taal versies, andere views voor andere taal op de hoofdtabellen). Ik kreeg een error bij de create trigger vanwege de with check option, maar hij werd toch gemaakt? En het lijkt alsof het goed gaat ...

[napel25]

Een groot voordeel van het gebruik van views over je schema is dat je je hele datamodel kunt omgooien zonder dat je applicatie plat gaat. Zo lang je de views maar beschikbaar houdt.
Als je dus van plan bent je database later uit te breiden of aan te passen, kan deze strategie je veel dubbel werk besparen.
Mijns inziens een van de (database)smaken met voor en nadelen...om nog maar us een open deur te doen...

[P_de_B]

napel25 schreef op maandag 27 juni 2005 @ 12:58:
Een groot voordeel van het gebruik van views over je schema is dat je je hele datamodel kunt omgooien zonder dat je applicatie plat gaat. Zo lang je de views maar beschikbaar houdt.
Als je dus van plan bent je database later uit te breiden of aan te passen, kan deze strategie je veel dubbel werk besparen.
Mijns inziens een van de (database)smaken met voor en nadelen...om nog maar us een open deur te doen...

En je benst instead of triggers aan het maken om een simpele insert te doen.....

Views zijn prima hoor, maar zodra je met iets als bovenstaande te maken hebt moet je m.i. gewoon in de tabel inserten. Daar hoef je je hele security ook niet voor over de kop te gooien.

[whoami]

napel25 schreef op maandag 27 juni 2005 @ 12:58:
Een groot voordeel van het gebruik van views over je schema is dat je je hele datamodel kunt omgooien zonder dat je applicatie plat gaat. Zo lang je de views maar beschikbaar houdt.
Als je dus van plan bent je database later uit te breiden of aan te passen, kan deze strategie je veel dubbel werk besparen.
Mijns inziens een van de (database)smaken met voor en nadelen...om nog maar us een open deur te doen...

Tja, dan moet je toch je view aanpassen.
Als je een grote applicatie hebt, die je in een meerlagenstructuur hebt opgezet, dan moet je bij een DB aanpassing enkel je DAL aanpassen (en evt ook BLL natuurlijk - maar dat moet je bij een view ook doen).

[napel25]

P_de_B schreef op maandag 27 juni 2005 @ 13:10:
[...]


En je benst instead of triggers aan het maken om een simpele insert te doen.....

Views zijn prima hoor, maar zodra je met iets als bovenstaande te maken hebt moet je m.i. gewoon in de tabel inserten. Daar hoef je je hele security ook niet voor over de kop te gooien.

Dat iets moeilijk is maar wel kan, is al een stuk beter dan dat het helemaal niet kan.

whoami schreef op maandag 27 juni 2005 @ 13:19:
[...]


Tja, dan moet je toch je view aanpassen.
Als je een grote applicatie hebt, die je in een meerlagenstructuur hebt opgezet, dan moet je bij een DB aanpassing enkel je DAL aanpassen (en evt ook BLL natuurlijk - maar dat moet je bij een view ook doen).

Inderdaad is de noodzaak van een view-laag minder wanneer de applicatie netjes is opgezet. Maar het is waarschijnlijk overbodig te zeggen dat applicaties niet altijd netjes worden ontwikkeld. Zeker wanneer een applicatie nou eenmaal gemaakt is valt op DAL nog BLL iets te scoren.
In dat geval is het prettig een extra laag in je database te kunnen bouwen. Dit kan trouwens vaak ook wanneer een database in eerste instantie niet op die manier is opgezet. Je kan vaak een schema simuleren met views.
Wanneer je applicatie alleen met stored prcedures communiceert, heb je nog een laag. Dan heb je als beheerder nog meer vrijheid...meer is beter...