table / form design help..

[don]

I'm building a process-flow type program, keeping track of 20-30 steps and
sign-off dates and emp Ids. I'm wavering between a flat table design, with
all these and other fields in 1 row; or a table of just the sign-offs, like:

job#
step
EmpID
Date

I'm more inclined to do this for one of the forms will list latest tasks
completed for all jobs by a client. Flat file would make this cumbersome..

But another form will show all the steps for a certain job, and seems to
favor a flat file layout with all fields in 1 row:

Job A
Step 1 - Completed: 5/1 - Inits DM
Step 2 - Completed: - Inits
Step 3 - Completed 5/3 - Inits JZ
Step 4 - Completed - Inits
Step25

Here with a flat org. with all data in 1 row, its simple to assign the form
fields to the 1 row. With non-flat org, and returning multiple rows of tasks,
assigning them into the proper spots on form is what I can not figure.

Again, not all steps may be used, and possible not completed in order.

Any ideas appreciated!!
thanks

 

[Fred]

Well, this is just my 2 cents:

My advice is that priorities and sequence should go like this:
1. Define the process / situation that you are recording, and, in non-DB
terms, what the mission pf the DB is.
2. Define table structure
3. Decide on forms and queries
4. Implementation details.

And that your approach & priorities in what you told us a lot a little
about seem to reverse the above. And so you didn't tell enough about #1,
leaving us to imply.

I think that your main / most frequent data element is steps. Your list
implies that you only record one event for a step (completion). (Everything
I write presumes this.) You didn't say whether or not you list / record
steps that have not been completed. Depending on this answer, your
main/common data element will be either "Steps" or "Completed Steps.

Also "Job" (PK = JobNumber) and and "Employee" (PK = EmpID) tables.

The table to have a "JobNumber" and "EmpID" field, with links to those
tables.

I think that everything that you want should drop out from the above
structure.

 

[Fred]

Speaking of implying without saying, I neglected to say, I talked about the
recommended main table without saying it. That "main/common data element is
also a table, and the main one.