Design of cross referring types/classes and proper usage of containers

[Serge Robyns <serge.robyns@gmail.com>]

I've a design issue with regards to what is the best if not ideal approach in building types or classes that refer to each other and could be aggregates.

Lets use an example  I've the following entity:

   type T_Client is tagged record  -- will be mapped a table
      Id         : Integer := 0;
      First_Name : T_Client_Name := T_Client_Name (P_Empty_String);
      Last_Name  : T_Client_Name := T_Client_Name (P_Empty_String);
   end record;

This is to keep track of client info.

I've the following other entity amongst others.

   type T_Subscription is tagged record  -- will be mapped to a table
      Name    : T_Subscriptiont_Name := No_Subscription_Name;
      Product : T_Product_Name := No_Product_Name;
      Client  : T_Client := No_Client;   -- Could also be of the same type T_Client.Id, used in different approach.
      Date    : Ada.Calendar.Time := GNAT.Calendar.No_Time;
   end record;

And I've other entities as well that do have similar relationships.

The application is keeping parts of the (static) data in memory but eventually all the data will be retrieved and stored into a database.  I'm planning to use a design pattern (bridge or others) to implemnent this step.

However, I'm wondering what would be the best Ada approach to have these objects interacting, i.e, referring to each other.  Currently I'm using the db approach, which means I use keys to search in various independant containers.

But why not for example, Client that could have an Ada container of T_Subscriptions.  This container could be either the object itself or a reference (access) or why not a Cursor to another Container containing all subscriptions.  The same applies for the client in the subscription.

And I've a few other of such entities/cases.

I'm all ears to the audience experience in this matter.

Regards,
Serge