Encrypting the relationship between two database tables I'm not a cryptography expert myself, and know enough to know that I shouldn't design my own crypto schemes, so I thought I'd seek advice here.

In an application, let's say we have two database tables: Lawyers and Clients. There exists a many-to-many relationship between these two models, so a Lawyer can have many Clients and a Client can have many Lawyers. As is typical in relational databases, there is a Join Table containing pointers to rows in each table in order to define the relationships between them.

The columns for the Join Table might look like this:

id | client_id | lawyer_id

Now let's say that in our security model, information about lawyers and information about clients are not considered privileged information on their own, so there's no need to encrypt them in any way. However, information about the relationship between Lawyers and Clients is privileged information that we would like to protect in the event an attacker gains access to the database.

Does there exist a common encryption scheme that securely encrypts client_id and lawyer_id without rendering the Join Table useless?
Provided that any user, who is supposed to have access to any relationship, may be granted access to all relationships, one solution would be to use a SQL engine that supports table level access control through table encryption, and encrypt the Join Table. In such case a decently implemented symmetric encryption scheme would be sufficient.

An attacker who gains physical access to the database files, will need the key for the Join table to be able to extract information from it. Conversely, if the attacker gains guest access to the database through the SQL interface, privilege elevation would be required to gain Join Table access. 

However, such solutions are not sufficient e.g. in scenarios where any client is supposed to be able to run a query for his or her own lawyers, or conversely, where some lawyers are not allowed to run queries for any clients but their own. In such case, a trivial solution would be to encrypt each record separately, using a symmetric encryption scheme under a randomly generated content encryption key that, in turn, is encrypted using e.g. RSA-OAEP and the public RSA key of each user that is supposed to have access to the record, with the RSA cipher texts being stored in a fourth table. Such schemes would require the join process to be implemented to run locally (since the process would need access to the RSA private key). 

Another alternative altogether would be to use Predicate Encryption, but such schemes are arguably very far from "common"-