Home/ Questions/Q 3481396
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T10:26:38+00:00

I’m designing a SQL Server 2005 database for a bank to hold records relating

  • 0

I’m designing a SQL Server 2005 database for a bank to hold records relating to clients (parent table) and their portfolios (child table), with each client having multiple portfolios. Tables so far:

Client (Client_Number PK ...)

Portfolio (Portfolio_ID PK, Client_Number FK ...)

I need to include a table to hold records for related third parties (e.g. Fund Manager, Administrator, Promoter etc.). The third parties are undetermined and liable to change, as are the relationship types. The relationships are obviously many-to-many, so I was thinking additional tables as follows:

Third_Party (Third_Party_ID PK, Third_Party_Name ...)
Relationship (Relationship_ID PK, Third_Party_ID FK, Client_Number FK ...)

This would work fine, but, the third parties can be related to Portfolios (child table) as well as Clients (parent table).

For example, Client 1 has Portfolio 1 and Portfolio 2. Client 1 and Portfolio 1 are linked to Promoter 1 but Portfolio 2 is linked to a different Promoter.

Any idea as to best practice for table design for the above situation?

Thanks in advance.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would go for two additional tables:

    Client_ThirdParty
Portfolio_ThirdParty

    Which would act as link entities between the two existing tables and ‘ThirdParty’. I would steer clear of the ‘Relationship’ table which looks like metadata in disguise.

    EDIT

    For example, Client 1 has Portfolio 1
    and Portfolio 2. Client 1 and
    Portfolio 1 are linked to Promoter 1
    but Portfolio 2 is linked to a
    different Promoter.

    Do you mean three additional tables?
    ThirdParty, Client_Relationship and
    Portfolio_Relationship? I ask this as
    both Client and Portfolio
    relationships are to a single ‘pool’
    of Third Parties.

    OK, if there are further relationships to consider then you may need more complexity (but as I don’t know your data I may miss something!):

    • Clients can have many Portfolios
    • Clients can have many ThirdPartys
    • Portfolios can have 1 Client?
    • Portfolios can have many ThirdPartys
    • ThirdPartys can have many Clients
    • ThirdPartys can mave many Portfolios

    If this is correct then:

    Client  
Portfolio (contains ClientId to refer to its client)
ThirdParty

Client_ThirdParty  <-- link entity that handles the Client/ThirdParty M-to-M
Portfolio_ThirdParty  <-- link entity that handles the Portfolio/ThirdParty M-to-M
    • 0