Design question: one big field or slave table

Hi every one!

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...

What are the defaults of enlarging the current "lot number" field to let the user enter more than one data? Of course, a little treatment would check the format string.

Thanks in advance, any help would be very appreciated

Matthieu Received on Wed May 03 2006 - 07:38:49 CDT