Jump to content

Should I save all user inputs into 1 table or separate?


DeX

Recommended Posts

I have a quoting system and the user (administrator level) has the ability to add or remove the inputs it requests of the salesman when doing the quote. There are a few locked inputs which can't be modified but otherwise if the user wants to collect which colour socks the customer has on, they are free to do that by adding an input to require it when doing the quote. Because of this, I'm currently taking all inputs on the page and throwing them into a match table in the database when each quote is saved.

 

I'm also taking the locked quote-specific inputs and putting those into corresponding spots in another QUOTE table with just information about the quote. This would include the width / length / height of the structure and the date it was quoted. I would also use the ID of the row from this insert as the quote ID which would be placed on the printed quote as a reference number.

 

I'm also taking locked customer-specific data and entering that into a CUSTOMER table and using the auto generated ID of this row as the customer ID.

 

The issue I'm having is I'm now duplicating some of the inputs in multiple tables and I'm wondering if I should just keep them all in the match table with all the other inputs and just let the model retrieve them from there when needed. I would then use the same ID for the quote and the customer ID in this case.

 

What do you think?

Link to comment
Share on other sites

You should start with an analysis of what you are trying to store and evaluate what your tables need to look like. Obviously you need to define a key field (or two?) that will help you identify the sets of data you will build. Then you need to clearly define what each field(column) of data is to represent and how it is to be stored and how large it may be. Give each of the fields meaningful (but reasonable short) names. When you find yourself with multiple values for a single field (b) you will need to break this one out to a separate table, using the same key info to mark those records as you do in the first table. If you find that you have multiple "sets" of the same data then you can save them as separate records in the primary table instead © using a key value that helps to make these records unique if you need to locate specific sets of data later on. You should never join differing values of the same data into one field/column using a separator character to later break them apart. Never. This is when you do what I mentioned earlier as (b).

 

Once you design your database it will be much easier to write the input forms and scripts to handle them.

  • Like 1
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.