I de flesta webbapplikationer är säkerhetsmodellen definierad i affärslogiklagret, inte datalagret.
Till exempel, min förmåga att redigera ett inlägg på Stack Overflow styrs inte av min förmåga att läsa/skriva till tabellen "inlägg" - i själva verket skulle du förmodligen inte ens kunna designa ett databasschema som skulle tillåta dig att implementera databasnivå säkerhet på denna nivå. Istället finns det ett lager för affärslogik som jämför mina privilegier med den åtgärd jag försöker vidta (förmodar jag); säkerhet implementeras i affärslogikskiktet.
Jag ser uppriktigt sagt nästan ingen fördel med att skicka igenom referenser till databaslagret - om jag på något sätt hade kringgått affärslogiken för att kontrollera vem som kan redigera SO-inlägg, skulle inte databasens "läs/skriv"-kontroller förhindra det, och revision skulle inte riktigt hjälpa dig.
Jag ser MÅNGA nackdelar - inte minst det faktum att du kommer att dela upp din auktoriseringslogik i två (affärslogik och databas) och introducera alla typer av underhållande fellägen med synkronisering av konton över ditt affärslogiklager och databaslager (användare som ändrar sina lösenord eller lämnar webbplatsen). Jag kan inte börja föreställa mig hur du vettigt skulle kunna testa och felsöka allt detta - vad händer om en slutanvändare får ett fel relaterat till sina databasrättigheter?