Hi guys, I have 2 Tables with a One-To-Many Relationship. The first Table, lets say Table a, is a big Table which contains the columns Date, customerID and Revenue. The second Table b contains Date, customerID, wealth and adress. but only of a few (premium) rich customers. It´s possible, that we have more than one Observations with the same Date and Customer ID in Table 1 (If he buys more than one products in one month), in Table b, only one Observation for each Date/CustomerID-Combination is possible. So, the Tables could look like this: data a; input date $ customerId $ Revenue $ ; datalines; 01JAN01 1 10 01JAN01 1 20 01JAN01 2 30 01FEB01 1 400 01FEB01 2 50 01FEB01 3 60 01FEB01 4 30 01MAR01 1 60 01MAR01 2 30 01APR01 1 60 01APR01 2 60 01MAY01 1 800 01MAY01 2 608 01MAY01 2 67 01MAY01 4 65 01MAY01 5 644 ; run; And Table b could look like this: data b; input date $ customerId $ wealth $ Adress $; datalines; 01JAN01 1 1000 Stockholm 01JAN01 2 2000 Paris 01FEB01 1 4000 Munich 01MAR01 1 6000 New York 01MAR01 2 3000 Cologne 01MAR01 3 3000 London ; run; Now, I want to make an Inner Join to join both Tables when a.Date = b.Date and a.CustomerID = b.CustomerID. The final table should have the following columns: date, customerID, Revenue and wealth. In case that the criteria is met for more combinations of table a, the desired table should contain all rows. So in this Scenario, the final table should look like this: Date CustomerID Revenue Wealth Jan 01 1 10 100000 Jan 01 1 20 100000 Jan 01 2 30 300000 Feb 01 1 30 120000 Mrz 01 1 510 130000 Mrz 01 2 10 200000 Mrz 01 3 10 500000 This would not be a Problem with SQL, but my Professor wants that I use a Hash-Table, because for large datasets, this would be more efficient. Could someone kindly provide me a Hash Solution for this? Note: This is just a simplified example that I´ve made. Pls don´t care about the sense of the data, let´s say rich customers can Switch their adress and wealth every month or can be banned from the premium list in every month 🙂 With the kindest regards, Alex
... View more