A secret which is shared by more than two people is not really a secret anymore.
Encrypting the data with a symmetric key K, and then encrypting K with the asymmetric (RSA) key of each recipient, means giving access to the recipient to all the data encrypted with K; "all the data" includes that which will be encrypted with K. This encryption method is the normal situation for secured emails (e.g. with OpenPGP), but a crucial point is that an email is "one shot" and each email is encrypted with its own, specific, random K.
With a database, things are more hairy, because a database is a set of data which evolves over time. By giving K to each user, you potentially allow them to read the database contents not only right now, but also the future contents which will be added later on. This is not necessarily a problem: as long as a given user has access to a database, he can (at least theoretically) dump all the data into a file of his own, and there is no way to make him "forget" the data. However, in the long run of things, this calls for key updates.
For instance, suppose that, at some point, you want to grant access to the database to a new user. This is simple: simply encrypt K with the RSA key of that new user. The dual operation of removing a user is more complex. Since you cannot force users to forget data, the best you can achieve is to deny access to new data (data which is added after the user removal), and this implies choosing a new K' distinct from K (and K' must not be computable from K, so we are talking about selecting a new random K' from scratch). So there are two choices:
Set your database format so that each record can be tagged with an identifier for the key K which is used for that record. Each key update implies creating a new K with a new identifier, and using that new identifier in each newly added or modified record. A repository for all the encrypted K is maintained (indexed by identifier and by user). Upon usage, each user accesses the repository by using the tag on the target record, so as to obtain the key K which is to be used to decrypt the record.
When the key is updated, all the data in the database is decrypted with the old K and reencrypted with the new K. A repository for the encrypted version of each K (indexed by user) is maintained.
The second method makes storage simpler, and have the nice benefit of "kicking out" removed users (in the attack model, we assume that a removed user took care to copy all the data he could, but if he did not, then kicking him out explicitly cis nice). However, key updates with the second method can be quite expensive, depending on their frequency and the database size. The first method is more generic and allows for fine-grained access control (e.g. making data accessible to some subsets of users).
Microsoft SQL Server has a lot of support functions (as the SQL language level) to implement such things (however, be warned that Microsoft documentation on cryptographic elements has an irksome tendency of redefining terminology, sometimes abruptly in the middle of the documentation itself).
