Design question: one big field or slave table

I've got a design question:
Currently, we've got a table called "session" which contains all data about a production session. I won't explain what is exactly a "session", that's not the scope.
In this table, a field holds a "lot number", the "lot number involved suring a session.

For now, the business needs the ability to records multiple lot numbers per session. So there are several lot numbers for one session record. The good way of DB design suppose to extract the "lot number field" in a child table that would make the link between a "session" and a "lot number" with, why not, a unique ID primary key.

This design would complicate the magangement application design: hard to display in a grid all sessions with its lot numbers (separated by commas for instances), performances issues (joins), grouping, cursor processing, etc...