Bad table design ok for this? 1

[jadams0173]

I have an a2k db with a vb6 front end. I have a table (or will have soon) that will store the last operations a user selects to view. There could be as few as 1 and as many as 25. If the user selects a work order that has already been viewed by them or someone else, I need to repopulate the form with the last viewed operations. That's all this table is for and I can't forsee ever having to use the column in this table for criteria.

I'm thinking of making the table structure like:

ID(PK) HeaderID(FK) Operations

where ID is an autonumber and HeaderID is the PK from the Header table. Then I'm thinking of storing the operations comma deliminated like opa, opb, opc and split them when I retrieve them. If I do this I can keep a 1 to 1 relationship with my header table and use one query to return the data.

Is this a bad idea from the start?? I know it violates first normal form because the data stored is not atomic.



I tried to have patience but it took to long! -DW

 

[johnwm]

Just put each op on a single entry. That way you don't have to worry about number of ops, you don't have to do any back end splitting and you don't have to do update queries with string manipulation to add new entries.

A simple WHERE which fetch all the required ops for each header

___________________________________________________________
If you want the best response to a question, please check out FAQ222-2244 first.
'If we're supposed to work in Hex, why have we only got A fingers?'
Drive a Steam Roller
Steam Engine Prints

 

[jadams0173]

Thanks for the reply johnwm. I'm going to do it the way you suggest. I think in the long run I will be glad I did. Thanks.

I tried to have patience but it took to long! -DW