Re: Design question: one big field or slave table

Matthieu wrote:

> 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

There are well-known problems with what you are proposing. The first hint is the dbms is a logic system and a database is a set of facts. Does your business need to make logical inferences about lot numbers or about arbitrary strings that may contain lot numbers?

Whether it makes sense to have multiple lot number attributes depends on what a lot number is and why one might have multiple of them.

Anyone who pretends to have answers to your questions, while ignorant of the myriad requirements that you have not included here, is a crank. Received on Wed May 03 2006 - 15:12:14 CEST