DeX Posted February 7, 2017 Share Posted February 7, 2017 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? Quote Link to comment https://forums.phpfreaks.com/topic/303119-should-i-save-all-user-inputs-into-1-table-or-separate/ Share on other sites More sharing options...
benanamen Posted February 7, 2017 Share Posted February 7, 2017 Look up and learn Database Normalization. Quote Link to comment https://forums.phpfreaks.com/topic/303119-should-i-save-all-user-inputs-into-1-table-or-separate/#findComment-1542421 Share on other sites More sharing options...
ginerjm Posted February 7, 2017 Share Posted February 7, 2017 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. 1 Quote Link to comment https://forums.phpfreaks.com/topic/303119-should-i-save-all-user-inputs-into-1-table-or-separate/#findComment-1542427 Share on other sites More sharing options...
NotionCommotion Posted February 8, 2017 Share Posted February 8, 2017 I agree with ginerjm that the database should surely be vetted out before coding. But before designing the database, make sure you accurately understand user requirements! Quote Link to comment https://forums.phpfreaks.com/topic/303119-should-i-save-all-user-inputs-into-1-table-or-separate/#findComment-1542439 Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.