Re: Very large from
Hmmm... Let me say some thoughts... First *fbsd_user* said that he has *100 input fields plus 40 different drop downs.* And everybody is arguing that they prefer *one single insert*. Is it just me... or are you thinking at a table with 140 columns ? Thinking at such a monster... all the above discussion is ok ! But who does a table with 140 columns... It's not good practice... it's no good at all... If we're not working with a monster like that... all discusion falls down... On the other hand if I have to insert all that info... in let's say... I don't know... 10 tables... what's the point of using *one single insert* how ca one use a one single insert to put data in 10 tables ? So... the design of the application follows in at least 50% of the cases the design of the DATABASE ! Give us a little more details about your database ! -- Gabriel PREDA Senior Web Developer
Re: Very large from
You could also use a temp table, put data into it page-by-page and insert the complete row after a last check into the real table. This temp table might have an additional timestamp field according to which evth. older than 1h(or some other time period) could easily be deleted by a cronjob. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Very large from
Thank you Gabriel, more background information may result in a better concept, so here it is. The web based application I am writing deals with people who have an a home for rent. They can sign up for small fee and enter their rental property into the application so its searchable and viewable by the internet public. I have a membership DB with single members table containing 20 columns which holds the users signup info. Members can list more than one rental property. Members has opportunity to enter some portion of the 140 columns of data to describe the rental property. Currently the real_estate DB contains a single property table of 140 columns. I have grouped the info in the table into 3 groups, mandatory info deals with the business of renting, second group deals with location, third group deals with house characteristics. All the 140 columns of data will be shown on the detail property screen. Fields that don't pertain to that individual property will show up as blank because the user did not enter data. All fields are 'varchar' to conserve on unused space. One single record per listed property has all the info retrievable by one read, but has undesirable effects entering all of it from single form. Making 3 tables would mean duplication of some common key fields to allow retrieving all the associated rows to combine the data for displaying. I would think since most of the activity will be people on the internet searching for rental property, performance would be better to retrieve all the info with a single read. This makes the 3 table idea a bad performer. It has been suggested to use session control as a staging function where the forms store the entered data so a single insert of all the data can be made to the table. Sessions store their data in standard flat files in /tmp. Flat files are not known for their access speed and performance, with 2 or 3 fields this is ok but 100+ fields and this may become a major performance bottleneck. My current thinking is to break the entering of the property info into 3 separate forms, the first with the mandatory info does a insert to create the row with the remaining 100 columns being seeded with $t=''. Group 2 3 will them be a update to the row using the 'set' keyword just touching the columns under their separate control. Does this sound like a workable solution or is there some other approach that is better suited to my application? Thanks to all the people who have replied all ready. -Original Message- From: Gabriel PREDA [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 5:01 AM To: Mysql Subject: Re: Very large from Hmmm... Let me say some thoughts... First *fbsd_user* said that he has *100 input fields plus 40 different drop downs.* And everybody is arguing that they prefer *one single insert*. Is it just me... or are you thinking at a table with 140 columns ? Thinking at such a monster... all the above discussion is ok ! But who does a table with 140 columns... It's not good practice... it's no good at all... If we're not working with a monster like that... all discusion falls down... On the other hand if I have to insert all that info... in let's say... I don't know... 10 tables... what's the point of using *one single insert* how ca one use a one single insert to put data in 10 tables ? So... the design of the application follows in at least 50% of the cases the design of the DATABASE ! Give us a little more details about your database ! -- Gabriel PREDA Senior Web Developer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Very large from
A power bar is what they call the bar at the bottom and on the right side of the browsers window when the content being showed in the window is larger than the window. By sliding the bars around you bring the content into view. -Original Message- From: James Harvard [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 6:39 PM To: Mysql Subject: Re: Very large from At 4:24 pm -0500 14/3/06, fbsd_user wrote: user has to use the power bar to move deeper into the form Out of curiosity, what's the power bar? From a db perspective one single insert is preferable, IMO. Firstly you don't have to declare as NULL required fields that will be entered in the second, third or Nth form page. Secondly you won't get incomplete entries, as has already been mentioned. If it was a sign-up form, say, and you have a unique index on the user e-mail address, then you would run into problems if a user completed the first page of the signup and created a new row in the table, then for some reason started from scratch (e.g. their 'puter crashed). They wouldn't be able to start again because their e-mail address would already be in the unique field in the table. I would do one of two things: a) use a session management system to store the submitted details until you get to the final form page and can insert the whole lot into the table b) Have the whole form on one page and use Javascript to only show one part of the form at any one time (but in such a way that it degrades gracefully for non-JS browsers - i.e. they get the whole form on one page) James Harvard -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Very large from
under the particular confinements you have set yourself, i would use the session id to create a temporary table that you can update when each stage of the form is complete. At the end you can present the user with all the data they have entered so far and give them the option of editing or confirming their input. Then, obviously you can copy the contents of the temporary sessionid table into your main one and drop the temporary. Still do not think i would use a table with 140 columns though, think about future use/how your project may develop before committing yourself. Good luck Pure Web Solution http://www.purewebsolution.co.uk PHP, MYSQL, Web Design Web Services fbsd_user [EMAIL PROTECTED] wrote: Thank you Gabriel, more background information may result in a better concept, so here it is. The web based application I am writing deals with people who have an a home for rent. They can sign up for small fee and enter their rental property into the application so its searchable and viewable by the internet public. I have a membership DB with single members table containing 20 columns which holds the users signup info. Members can list more than one rental property. Members has opportunity to enter some portion of the 140 columns of data to describe the rental property. Currently the real_estate DB contains a single property table of 140 columns. I have grouped the info in the table into 3 groups, mandatory info deals with the business of renting, second group deals with location, third group deals with house characteristics. All the 140 columns of data will be shown on the detail property screen. Fields that don't pertain to that individual property will show up as blank because the user did not enter data. All fields are 'varchar' to conserve on unused space. One single record per listed property has all the info retrievable by one read, but has undesirable effects entering all of it from single form. Making 3 tables would mean duplication of some common key fields to allow retrieving all the associated rows to combine the data for displaying. I would think since most of the activity will be people on the internet searching for rental property, performance would be better to retrieve all the info with a single read. This makes the 3 table idea a bad performer. It has been suggested to use session control as a staging function where the forms store the entered data so a single insert of all the data can be made to the table. Sessions store their data in standard flat files in /tmp. Flat files are not known for their access speed and performance, with 2 or 3 fields this is ok but 100+ fields and this may become a major performance bottleneck. My current thinking is to break the entering of the property info into 3 separate forms, the first with the mandatory info does a insert to create the row with the remaining 100 columns being seeded with $t=''. Group 2 3 will them be a update to the row using the 'set' keyword just touching the columns under their separate control. Does this sound like a workable solution or is there some other approach that is better suited to my application? Thanks to all the people who have replied all ready. -Original Message- From: Gabriel PREDA [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 5:01 AM To: Mysql Subject: Re: Very large from Hmmm... Let me say some thoughts... First *fbsd_user* said that he has *100 input fields plus 40 different drop downs.* And everybody is arguing that they prefer *one single insert*. Is it just me... or are you thinking at a table with 140 columns ? Thinking at such a monster... all the above discussion is ok ! But who does a table with 140 columns... It's not good practice... it's no good at all... If we're not working with a monster like that... all discusion falls down... On the other hand if I have to insert all that info... in let's say... I don't know... 10 tables... what's the point of using *one single insert* how ca one use a one single insert to put data in 10 tables ? So... the design of the application follows in at least 50% of the cases the design of the DATABASE ! Give us a little more details about your database ! -- Gabriel PREDA Senior Web Developer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Very large from
My current thinking is to break the entering of the property info into 3 separate forms, the first with the mandatory info does a insert to create the row with the remaining 100 columns being seeded with $t=''. Group 2 3 will them be a update to the row using the 'set' keyword just touching the columns under their separate control. Does this sound like a workable solution or is there some other approach that is better suited to my application? If you go this route I would set some kind of 'finalized' flag when the user completes the third group (even if they left everything in this group blank). This way you can easily clear out abandoned registrations, where the user completed step 1 but then bailed out for some reason. But I doubt you'll have a ton of users entering in property at one time, I think you even said most of your traffic would be browsing and reading the listings. So I don't think it would be a problem to build up all the data in a session and then write it all at once at the end. -Ryan -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Very large from
fbsd_user wrote: Thank you Gabriel, more background information may result in a better concept, so here it is. The web based application I am writing deals with people who have an a home for rent. They can sign up for small fee and enter their rental property into the application so its searchable and viewable by the internet public. I have a membership DB with single members table containing 20 columns which holds the users signup info. Members can list more than one rental property. Members has opportunity to enter some portion of the 140 columns of data to describe the rental property. Currently the real_estate DB contains a single property table of 140 columns. I have grouped the info in the table into 3 groups, mandatory info deals with the business of renting, second group deals with location, third group deals with house characteristics. All the 140 columns of data will be shown on the detail property screen. Fields that don't pertain to that individual property will show up as blank because the user did not enter data. All fields are 'varchar' to conserve on unused space. One single record per listed property has all the info retrievable by one read, but has undesirable effects entering all of it from single form. Making 3 tables would mean duplication of some common key fields to allow retrieving all the associated rows to combine the data for displaying. I would think since most of the activity will be people on the internet searching for rental property, performance would be better to retrieve all the info with a single read. This makes the 3 table idea a bad performer. Why? It has been suggested to use session control as a staging function where the forms store the entered data so a single insert of all the data can be made to the table. Sessions store their data in standard flat files in /tmp. Not in my system. I have a session table that has records that consist of: session id variable name value Flat files are not known for their access speed and performance, with 2 or 3 fields this is ok but 100+ fields and this may become a major performance bottleneck. My current thinking is to break the entering of the property info into 3 separate forms, the first with the mandatory info does a insert to create the row with the remaining 100 columns being seeded with $t=''. Group 2 3 will them be a update to the row using the 'set' keyword just touching the columns under their separate control. Does this sound like a workable solution or is there some other approach that is better suited to my application? Thanks to all the people who have replied all ready. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Very large from
Have to develop form with over 100 input fields plus 40 different drop downs. Seeking advice on technique to use. Thinking about single form where user has to use the power bar to move deeper into the form. This has benefit that every thing is written to the database at one time, but the draw back is the user frustration in entering so much data at one time. Alternate thoughts are breaking it down into 2 or 3 separate pages with each page being written to the data base. First page does a insert to create the row, then following pages do updates to complete populating the row with data. Has anyone done anything like this or have seen this done before. What advice can you offer. Where to look for examples. Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Very large from
Both methods are commonly used. Another method used is to have multiple pages like you've mentioned but save all the data into a session (of just pass it from page to page) until all 3 pages are complete and then write all the data at once The question to ask yourself is, do you want just partial data, an incomplete form, to be in your database/table. If you don't, then method 1 or the method I just mentioned is the way to go. Otherwise you'll have incomplete data in your dataset. Surveys do both of any/all 3 of these methods. Of course, with ajax now, I'm seeing more written to the database while a user is inputing their data and then the web application has to remove, at some point, incomplete data. Good Luck! Have to develop form with over 100 input fields plus 40 different drop downs. Seeking advice on technique to use. Thinking about single form where user has to use the power bar to move deeper into the form. This has benefit that every thing is written to the database at one time, but the draw back is the user frustration in entering so much data at one time. Alternate thoughts are breaking it down into 2 or 3 separate pages with each page being written to the data base. First page does a insert to create the row, then following pages do updates to complete populating the row with data. Has anyone done anything like this or have seen this done before. What advice can you offer. Where to look for examples. Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- /Brett C. Harvey; /Creative-Pages.Net, President; /Facility Management Systems, CTO (www.fmsystems.biz); /Lasso Partner Association Member ID #LPA135259 (www.omnipilot.com/www.lassopartner.com); -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Very large from
Not wanting to be rude but this question would probably be answered better in a php group. I realise there are many users of php that subscribe to this list, but this is a mysql list not php. If you go to http://www.php.net/support.php you will find a large number of resources (including lists at http://www.php.net/mailing-lists.php), not to mention examples of code, irc channels etc. Regards fbsd_user wrote: Have to develop form with over 100 input fields plus 40 different drop downs. Seeking advice on technique to use. Thinking about single form where user has to use the power bar to move deeper into the form. This has benefit that every thing is written to the database at one time, but the draw back is the user frustration in entering so much data at one time. Alternate thoughts are breaking it down into 2 or 3 separate pages with each page being written to the data base. First page does a insert to create the row, then following pages do updates to complete populating the row with data. Has anyone done anything like this or have seen this done before. What advice can you offer. Where to look for examples. Thanks -- David Logan South Australia when in trouble, or in doubt run in circles, scream and shout -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Very large from
On Tuesday 14 March 2006 22:24, fbsd_user wrote: Have to develop form with over 100 input fields plus 40 different drop downs. Seeking advice on technique to use. Thinking about single form where user has to use the power bar to move deeper into the form. This has benefit that every thing is written to the database at one time, but the draw back is the user frustration in entering so much data at one time. Alternate thoughts are breaking it down into 2 or 3 separate pages with each page being written to the data base. First page does a insert to create the row, then following pages do updates to complete populating the row with data. Has anyone done anything like this or have seen this done before. What advice can you offer. Where to look for examples. Thanks Not knowing what language you use, how about a form consisting several tabs, where each tab contains grouped data? Switching from tab can be done by clicking on the tab itself or a Next button on each page... -- Peter M. Groen Open Systems Development Klipperwerf 12 2317 DZ Leiden T : +31-(0)71-5216317 M : +31-(0)6-29563390 E : [EMAIL PROTECTED] Skype : peter_m_groen -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Very large from
I understand the save the page form data into the session. But I don't know what you mean by just pass it from page to page. Would that mean having all the fields in regular form fields to accept the entered data and also hidden corresponding fields to hide page 1 data in as page 2 is entered and for page 3, page 1 2 would be in hidden fields? This results in all that data being passed back and forth between the web server and the user. This would really be slow for a dial up user. Or am I not understanding what you were talking about. Using the 3 page method with data being written by page, I would have flag on the record which would not be a user input field, but a program control to identify the record as not usable until all 3 pages have been executed. Since all the fields are not mandatory there will always be empty fields and that is ok by business design. -Original Message- From: Brett Harvey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 4:35 PM To: [EMAIL PROTECTED]; mysql@lists.mysql.com Subject: Re: Very large from Both methods are commonly used. Another method used is to have multiple pages like you've mentioned but save all the data into a session (of just pass it from page to page) until all 3 pages are complete and then write all the data at once The question to ask yourself is, do you want just partial data, an incomplete form, to be in your database/table. If you don't, then method 1 or the method I just mentioned is the way to go. Otherwise you'll have incomplete data in your dataset. Surveys do both of any/all 3 of these methods. Of course, with ajax now, I'm seeing more written to the database while a user is inputing their data and then the web application has to remove, at some point, incomplete data. Good Luck! Have to develop form with over 100 input fields plus 40 different drop downs. Seeking advice on technique to use. Thinking about single form where user has to use the power bar to move deeper into the form. This has benefit that every thing is written to the database at one time, but the draw back is the user frustration in entering so much data at one time. Alternate thoughts are breaking it down into 2 or 3 separate pages with each page being written to the data base. First page does a insert to create the row, then following pages do updates to complete populating the row with data. Has anyone done anything like this or have seen this done before. What advice can you offer. Where to look for examples. Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- /Brett C. Harvey; /Creative-Pages.Net, President; /Facility Management Systems, CTO (www.fmsystems.biz); /Lasso Partner Association Member ID #LPA135259 (www.omnipilot.com/www.lassopartner.com); -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Very large from
Well not wanting to be rude back. But the question is dealing with how best to control the writing of data to mysql. No where do I say anything about using php. I could be using perl for all you know. But I respect your right to state your thoughts, but just don't agree with it. I think this is a better place to ask this question, and acknowledge that people on the php list would also most likely be able to shed light on this subject. -Original Message- From: David Logan [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 4:53 PM To: [EMAIL PROTECTED]; mysql@lists.mysql.com Subject: Re: Very large from Not wanting to be rude but this question would probably be answered better in a php group. I realise there are many users of php that subscribe to this list, but this is a mysql list not php. If you go to http://www.php.net/support.php you will find a large number of resources (including lists at http://www.php.net/mailing-lists.php), not to mention examples of code, irc channels etc. Regards fbsd_user wrote: Have to develop form with over 100 input fields plus 40 different drop downs. Seeking advice on technique to use. Thinking about single form where user has to use the power bar to move deeper into the form. This has benefit that every thing is written to the database at one time, but the draw back is the user frustration in entering so much data at one time. Alternate thoughts are breaking it down into 2 or 3 separate pages with each page being written to the data base. First page does a insert to create the row, then following pages do updates to complete populating the row with data. Has anyone done anything like this or have seen this done before. What advice can you offer. Where to look for examples. Thanks -- David Logan South Australia when in trouble, or in doubt run in circles, scream and shout -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Very large from
At 4:24 pm -0500 14/3/06, fbsd_user wrote: user has to use the power bar to move deeper into the form Out of curiosity, what's the power bar? From a db perspective one single insert is preferable, IMO. Firstly you don't have to declare as NULL required fields that will be entered in the second, third or Nth form page. Secondly you won't get incomplete entries, as has already been mentioned. If it was a sign-up form, say, and you have a unique index on the user e-mail address, then you would run into problems if a user completed the first page of the signup and created a new row in the table, then for some reason started from scratch (e.g. their 'puter crashed). They wouldn't be able to start again because their e-mail address would already be in the unique field in the table. I would do one of two things: a) use a session management system to store the submitted details until you get to the final form page and can insert the whole lot into the table b) Have the whole form on one page and use Javascript to only show one part of the form at any one time (but in such a way that it degrades gracefully for non-JS browsers - i.e. they get the whole form on one page) James Harvard -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
