Re: Design question: one big field or slave table

From: dawn <dawnwolthuis_at_gmail.com>
Date: 3 May 2006 11:57:12 -0700
Message-ID: <1146682632.898790.274010_at_g10g2000cwb.googlegroups.com>


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

Hi Matthieu. I don't know, but I'm guessing you will get more responses on comp.databases than here. There is no database "theory" that would suggest expanding the size of the field to handle multiple values in a single field would be a good idea when using a SQL-DBMS. Some folks might feel your pain, however, so you might ask what people have done in similar situations and specify which DBMS you are using. Best wishes. --dawn Received on Wed May 03 2006 - 20:57:12 CEST

Original text of this message