Represent many-to-many rel between BGP updates and BGP hijacks with intermediate table

[vkotronis]

Is your feature request related to a problem? Please describe.
Currently this is implicit on the site of the hijacks (is built in real time dynamically), and explicit on the site of BGP updates, albeit using a DB field that is a list of hijack keys. This creates many performance slow-downs when searching. The simplest way is to
use an intermediate table that stores the many-to-many rel referencing the primary keys/ids of the updates and hijacks. This requires heavy reformatting of code, but will have many benefits including the removal of ARRAY_REMOVE and array search actions, which may delay the system when the DBs are large.

Describe the solution you'd like
Intermediate table with foreign keys.

Describe alternatives you've considered
This is the most viable and DB-friendly change that we can induce, but requires single handling among the codebase to avoid issues.

Additional context
Arbitrary example with fkeys:

CREATE TABLE customers(
   customer_id INT GENERATED ALWAYS AS IDENTITY,
   customer_name VARCHAR(255) NOT NULL,
   PRIMARY KEY(customer_id)
);

CREATE TABLE contacts(
   contact_id INT GENERATED ALWAYS AS IDENTITY,
   customer_id INT,
   contact_name VARCHAR(255) NOT NULL,
   phone VARCHAR(15),
   email VARCHAR(100),
   PRIMARY KEY(contact_id),
   CONSTRAINT fk_customer
      FOREIGN KEY(customer_id) 
	  REFERENCES customers(customer_id)
	  ON DELETE CASCADE
);