To see the advantages of user-level security, consider this example: Suppose you have a Salary table and two groups of people who use that table — managers who can update the table and workers who can view but not update the table. In a user-level system such as one created with Microsoft Jet, you can assign update permissions for the Salary table to the managers group and read permissions to the workers group. Then you add each user in your system into one of these two groups. Once this is done, users log on using their user account name and password. They need to perform no other action to use the application. They are granted the appropriate level of access to objects based on the permissions settings stored with each object and their group membership as established when logging on to the system. The users manage their own passwords, and their passwords are used to verify their identity rather than to identify a permission for an object.
In a share-level system, two passwords would be used to implement this scheme: an update password and a read password, both applied directly to the Salary table. In this scenario, you would have to provide the passwords directly to the appropriate people. This is even more complicated if you have to change a password; you must have administrative mechanisms in place to make sure that all users get their appropriate updated passwords. Also, any time a user is moved from the managers group to the workers group, the password for the managers group must be changed to maintain security.
You can see that even in this simple scenario, the administrative overhead associated with share-level security can be substantial. When you imagine a real application with many tables, users, and groups, you can quickly see that share-level security is a cumbersome solution.