• Status: Solved
  • Priority: Medium
  • Security: Private
  • Views: 40
  • Last Modified:

Another way/better way of designing this page/table?

1. I have a page with some fields like first name, last name, address, city, etc.

2. Some fields are required and some aren't.

3. On the page, I want to have 2 buttons; "Save for later" and "Save & Submit"

4. I created two tables with the same fields. In one table (for Save-for-Later"), I have the fields as nullable.
     In the real table (table for Save & Submit), I have the required fields as non-nullable and the non-required ones as nullable.

So, I have 2 tables. I wonder if this is a good design. If I want to display ALL the data (complete and incomplete) in a table, I have to go to two tables and get the data. Maybe I need a "complete" flag?

Maybe I just need one Save-For-Later table and have all the fields as nullable. When user clicks on "Save & Submit".... I insert the row from one table to the other?

Any ideas or is my orig design idea is good?
  • 2
2 Solutions
Ryan ChongCommented:
So, I have 2 tables. I wonder if this is a good design. If I want to display ALL the data (complete and incomplete) in a table, I have to go to two tables and get the data. Maybe I need a "complete" flag?
it depends on how important is for those incomplete data ( after "Save for later" button was clicked" ) ?

if these data is crucial then you may put all data ( whether is for "Save for later" or "Save & Submit" ) into a single table, use a flag (like the field: complete) for completion indication.

if that's a scenario in which those data saved from "Save for later" will be purged after a certain period of time, OR in a situation that the rate of "Save for later" is significantly higher than the rate of "Save & Submit" then you may consider to put it on a separate table.
CamilliaAuthor Commented:
Thanks. If I put only use one table, then the "required" fields have to be nullable in the table. I think that's not a good design but it might be ok. I'll think about it more.
Scott PletcherSenior DBACommented:
First and foremost, a table design should have NOTHING to do with the screen(s) used for data entry.  The data itself is what should be modeled, not the current method of entering it.  (This is the main reason developers should never do db "design": because they model the interface/programming rather than the data!)

As to your specific q, you should have separate sets of tables (I'm virtually certain a proper data modeling would result in at least two tables).  You should not store "unreal"/tentative data with permanent data.  As you've noted, some values will not even be present until the data is finalized.  If those values end up being required key values in the actual tables, you wouldn't want to/be able to leave them empty even if you wanted to.
CamilliaAuthor Commented:
Thanks, Scott. I created 2 tables.

I thought about having one table with the required fields as non-nullable and populating them with a predetermined "dummy data" if user clicks "Save for Later" but I don't think that's a good idea. I'll go with 2 tables...one for real data and one for when user saves for later.

I can pull data from both tables and have a column in the grid to show which records are completed and which ones aren't.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now