Thanks Arjen, seems like a bit of a fiddle but not a bad solution considering some of the other options. Unfortunately I also need the row level locking of innodb so it's not going to work in my case. This lead me to ponder, if this sort of row level protection was added would it be at the mySQL level or the table handler level - ie do I need it in innodb table types or lower than that for it to work? I know this is sort of hypothetical at the moment but if it did get added then at what level it gets added would be of interest.
Thanks again for the thoughts, cheers, noel On Wednesday, February 20, 2002 8:47 AM, Arjen Lentz [SMTP:[EMAIL PROTECTED]] wrote: > Hi Noel, > > On Tue, 2002-02-19 at 13:40, [EMAIL PROTECTED] wrote: > > I'm wondering about row level privilages - being able to restrict what > > people see and can update etc on a row level as well as a column/table > > level. > > As others mentioned, having VIEWs wouldn't necessarily be of any help, > since VIEWs are quite restrictive about INSERT/UPDATE type operations on > the view. > > Anyway, after a little pondering, I think I've come up with a fairly > nice solution for this problem. It is MySQL specific though: > Use MyISAM MERGE tables (http://www.mysql.com/doc/M/E/MERGE.html). > > You can define a MERGE table, merging multiple *identical* MyISAM type > tables. It is a bit like a view, in a way. You can do a query on the > merge table, which will internally gather data from all the tables. > > How does this help you? You set up your permissions so that admin tools > have full access to the merge table and all its parts. For individual > users, you only grant access to their own table, to the extent that you > want. > > Some shuffling between tables might be required when a row is for > instance 'transfered' to another user, but I would figure that that is > fairly easy to handle. > > Anyway, this way the plain end-user application can be bound by the user > permissions, there's nothing specific the application needs to do, and > no way for the user to circumvent that system. > > This may not be suitable for every situation, but it might be useful > here.... > > > Regards, > Arjen. > > -- > Get MySQL Training Worldwide, http://www.mysql.com/training/ > __ ___ ___ ____ __ > / |/ /_ __/ __/ __ \/ / Mr. Arjen G. Lentz <[EMAIL PROTECTED]> > / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Technical Writer, Trainer > /_/ /_/\_, /___/\___\_\___/ Brisbane, QLD Australia > <___/ www.mysql.com > > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
