Sven K�hler wrote:
b) is what i worry about the most, because i might have to grant access for some data to some "untrusted" users ...
This may not be a good idea at all, "untrusted" users are commonly also remote users that you have little, so if you should want to change the schema then upgrading all these untrusted clients could be very hard...

Maybe it would be a good idea to write a layer inbetween the untrusted users and the database?

SAP DB can protect you from some stupid user doing "select * from huge,gigantic" afaik, but it can't protect you from bad programmers who do lots of little table scans, forcing these people to use your interface would also help ensuring that they don't go and do stupid things with the database...

A simpler solution that solves your references problem could be to not grant untrusted users access to create tables at all, but to have them request the creation of tables / foreign keys from you and then do the creation yourself.


You could also write a simple script that keeps an eye on the "foreignkeycolumns" table and whenever something changes check that it's allowed (between untrusted tables, trusted tables or that the "on delete"-clause is ok if it's a untrusted table referencing a trusted one), this would solve your problem if it ever happened, but it could leave a short window where you might see trouble.

HTH

--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker

_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general


Reply via email to