Kannst du ein etwas realistischeres Beispiel geben?
das
SQL von ersten Post macht ja reichlich wenig sinn:
SELECT d.* FROM datentabelle d, zugrifftabelle z WHERE d.mandant = z.mandant
IOW: Gebe mir x-mal die gleichen Rows aus d, schließlich wird z.mandant nicht eindeutig sein, oder? Und selbst wenn, wo ist denn da die Einschränkung?
Oder dachtest du an sowas?
SQL-Code:
SELECT d.*
FROM Datenzeugs d
INNER JOIN UserPrivileges up on up.Privilege = d.RequiredPrivilege
where up.UserName = Current_User()
Aber mal abgesehen davon, halte ich das für eine grauenvolle Idee...
Direkten Zugriff auf die
DB (nicht nur auf die Tabellen) sollte gar kein Normalsterblicher haben.
Wir schreiben fast 2010, nicht 1989. Klassische C/S Systeme in Bereichen wo man sich um Sicherheit und Zuverlässigkeit sorgen muss sind doch nun wirklich mehr als ausgedient.
Ist Zugriff für generische Reporting Tools (Crystal, etc) nötig, dann kann man sich zum Beispiel einen Simple-Mode OleDB Provider bauen. Oder einfach Reporting als Zusatzfeature mit anbieten.
Dann geht das alles geregelt durch den Appserver und nicht daran vorbei in die
DB.
Der Server wird stets und ständig aus allen Löchern pfeifen und er wird schneller einen Punkt erreichen, bei dem du noch soviel Hardware danach schmeißen kannst. Du wirst einfach nicht weiter skalieren können, wenn du mit solchen Views den
Query-Optimizer boykottierst.
Und das wiederum heißt, dass deine App ein Mindesthaltbarkeitsdatum auf dem Deckelrand gedruckt hat, ab dem man eine neue App brauchen wird, da diese irgendwann mit den wachsenden User und/oder Daten nicht mehr standhalten können wird.