• The basic design is quite simple. You have to create an interim table that has the primary key from patient and the primary key from pharmacy. That creates the many to many join that you need.

    Unfortunately, depending on how the data is coming from your pharmacy, loading this could be tricky. Are the primary keys for the patient unique across pharmacies? Or is it only unique within a pharmacy? If it's only unique within a pharmacy, then you have to have some other method of identifying patients. If all you have is first and last name, you're in trouble. There can be more than 'Li Wong' so just relying on the name is going to hurt you. With that other unique constraint you can just look up the primary key from the person as you perform the loads and put them into the interim table.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning