>>****snip****
>>schema
>>A named collection of objects, such as tables, views, clusters, procedures, and packages, associated with a particular user.
>>************
>>
>>I guess they break it down to what is available to a particular user...
>>
>>
>>- Brian
>
>To be precise, all database "objects" (such as tables, views, ....) belong to a particular user.
>
>All the objects that belong to a particular user are said to be in that user's schema.
>
>A user may have permissions to objects in another user's schema, and even have views that reference objects in another user's schema. The views are in their schema, the tables the views refer to are in another.


OK, so even though user A has permission to a table in user B's schema, only the view of that table in user A's schema is considered to be in user A's schema, but not the table itself. Right?


>
>As Mark has said, in an real-world scenario, you would typically create a "user" who is the 'Application Owner' and create the tables, views etc. you need under that user account (= in the 'Application Owner' schema).
>


Yep, Mark has helped me out with that in the past too. I'm playing around trying to find out what the bare minimum rights should be given to a group of users and how many there should be (groups that is). I guess one "application" user, one "application" group, with CONNECT, INSERT, UPDATE, DELETE would be the simplest approach, but is it the best?


>Clear as mud ;)
>

MUD? It's more like QUICKSAND! :O


- Brian