[SalesForce] Can Many to Many relationship be achieved using lookup relationship

A lookup (with Delete this record also) and master-detail share a large number of similarities:

• Deletion of the related record causes a cascade delete that does not invoke triggers.
• Both types of relationships are automatically indexed.

There are some trivial differences:

• Lookups are not required by default, where master-details are always required. Lookups can however be made required to share this behavior.

And there are some potentially major differences:

• Lookups do not support rollup summary fields (although there are community solutions available).
• Detail records do not have an owner, and thus do not have an ownerId field.
• Detail records cannot independently participate in sharing, the access to them is always controlled by the access level (require read vs write to edit detail records) set when defining the relationship. Records related via lookups have wholly independent sharing from the related record.
• Master-detail relationships cannot be to an object of the same type (e.g. MyObj_c to MyObj_c).
• You can have no more than 3 levels of master-detail relationships, meaning a parent, child, and grandchild object. On the other hand you can built almost infinitely complex networks of lookup relationships.
• There can be no more than two master-detail relationships on a object, and the first of the two has special behavior:

The first master-detail relationship you create on your junction object becomes the primary relationship. This affects the following for the junction object records:

• Look and feel: The junction object's detail and edit pages use the color and any associated icon of the primary master object.
• Record ownership: The junction object records inherit the value of the Owner field from their associated primary master record. Because objects on the detail side of a relationship do not have a visible Owner field, this is only relevant if you later delete both master-detail relationships on your junction object.
• Division: If your organization uses divisions to segment data, the junction object records inherit their division from their associated primary master record. Similar to the record ownership, this is only relevant if you later delete both master-detail relationships.

In the end which to select often comes down to how you want to impact your sharing and security model. Lookups allow much greater flexibility here, but often this will require code and apex managed sharing to make full use of, although it can be leveraged with sharing rules.

What you've described is not a one-to-many relationship, but rather a many-to-many relationship (a Gym can have many members, and a member can be associated with many Gyms).

To capture this in Salesforce, you'll need 3 objects. You already have 2 objects, Gym__c and Member__c. The third object sounds like it'll be Membership__c.

This concept is called a junction table, though in Salesforce it's known as a Junction Object. Membership__c would have a relationship to both Gym__c and Member__c.

In the Salesforce documentation, they say to make Membership__c be the master in two Master-Detail relationships (Gym__c and Member__c being the 'detail' sides of those Master-Detail relationships). Based on you saying that a Gym can have 0 members, and a member can have 0 gyms, this would be a lookup relationship instead.

If you continue on reading through that documentation link, it goes on to say that you could include fields from Member__c in the related list on Gym__c (and vice versa), even though the related list is to Membership__c. You might only be able to do this if you make Master-Detail relationships though (I'm not able to test this out myself at the moment).

Adding multiple members to a gym sounds like a separate question to me. This question may be a good place to start