Max fields per table?

Sure.... So for the project Notes that is a separate table that is related as a project does have many notes.

For the survey it is really more around data for a project.  Each project has one set of survey data.  For example, I will want to survey what electrical power is available in the building.  120 Volt, 208 Volt, 460 Volt, etc.  And be able to select multiple options there.

So each project has one set of building survey data.  Which ultimately might have 30-50 items on it.  So that as we are designing we can continually update the data on what is available to us from an infrastructure in the building standpoint.

We are basically an architectural design firm, so looking to capture electronically all of the information our field people get when surveying a client site and be able to add to it as we coordinate with engineers and other people.

So each project has one set of survey data.  And each set of survey data only belongs to one project.  It could be all in the projects table.  But I was wondering if that would be too much field wise for one table and we should have a one to one relationship?

I am envisioning all of this on a tab layout.  So the first tab is the project overview.  Project Name, client, project manager in the office, address, etc.  Second tab being the notes on the drawing and a running discussion board of open topics.  This third tab would contain all of the data around the survey.

I've seen tables with over a thousand fields and I'm sure people out there have more than that. Once you get over a certain amount it does become much slower and you have to really work with the form to make it still function well. At 50 fields you are not in danger of bad performance.

Got it, I am sure it might be above 50 as that wasnt meant to be literal.  But it is far from thousands.  I keep on expecting Quick Base to be less capable than I guess it really is!  Thats a good thing!

At this point it sounds like the distinction between the two approaches might be only stylistic. You could add the 100 survey fields to the project table with no performance impact, and sequester those fields using tabbed forms or other methods. I can see advantages and downsides to that approach.

You could also create a Project Surveys table with a one-to-one relationship to the Projects table and put just a report link to [Related Survey] on the Projects view form, plus maybe a handful of lookup fields you might need.

It really comes down to your preference, or maybe subtle elements of your users' actual workflow.

The other consideration is whether it will need to be an "admin function" to add or delete a question and what will happen to the historical projects if you delete a question (ie it will delete from all historical projects, which is bad).

Hence, I would recommend the child table approach.  

I cannot think of any reason I would ever delete a question unless it was a bad question and I was modifying the way it was presented.  In which case I am not sure if the data is useful or not.  So I am not terribly concerned about that but it is a very very valid point.

How do you create a 1 to 1 relationship in quick base?  I havent seen that yet.

Can you tell me why would you want to create s one to one relationship?

The only reason I could think of it based on all of this feedback was just to help simplify the development of the table.  It would keep all of the survey related fields seperate from all of the other fields.  However, that seems to only help the developer not the user at a potential slight cost of performance

Your user experience will be much better just to put the Survey fields on the Form in a Tab.