I'd say that you need to rethink your DB design: you seem to be trying to store multiple values in a single column of Table2 and assuming that they can be "back tracked" to Table1 easily. They can't, as the only way to store multiple values is via a string based column, and that means that each time you want to use them, you need to break up that string, convert the broken up bits into the same datatype as the ID column in Table1 (which is likely INT, probably IDENTITY) and store it in a temporary table for JOINing. While that is possible (Converting comma separated data in a column to rows for selection
]) it's very messy, very inefficient, and a PITA to maintain later.
Instead, look at your actual tables and the data they store - I doubt if it's as simple as you show - and work out how you need to store multiple values so that can be managed better.
I often end up with a third table which adds multiple items:
Table1 as yours,
ID INT, IDENTITY (or UNIQUEVALUE) identifies row, not teh same as your ID column
... other columns ...
That way, you can have as many or as few relationships between Table1 and Table2 as necessary for each row, and you can establish formal "one-to-many" relationships between your tables to enforce relational integrity when you make changes.