2 question about "pages"

[lundy]

I'm a beginner.  I have a question about how data is stored in PW.

1.  If I have the field "questions", and I want to store 10 seperate questions, are they stored as 10 individual pages, that are linked to the template, which is linked to the field "questions"?  If not, how are they stored.

2.  If they are stored as pages, is there some kind of limitations on the number of pages... example: pages > 1,000,000

Is there a limitation on concurrent outside-users adding pages? example 500 pages per minute?  

Thanks, just trying to understand... i've learned some from the basic tutorial, but still questions persist.

[Macrura]

the templates are really fieldsets - you would have to add the questions field to a template;

you could use a repeater field to store multiple iterations of a field on a page;

or you could store the 10 questions in a text field and then pull them each out using php, like for example if each question was on a newline, you could easily pull each one out and then foreach through them in order to output them anyway you want, be it <li> or <p>.

[lundy]

ok, but what if I have 1000's of questions, maybe even 10's of thousands, is it better to create a page for each question, or is there a better way?

[Macrura]

yes, you could definitely use pages to store questions, pages are the 'cellular' object in PW, they can represent anything you want them to, folders, bits of data, chunks, whatever;

you could create a template called questions and then another one called question, and then allow only pages with the question template as children of the questions template; then you could import your questions using the csv module or the api.

[lundy]

would it be accurate to say a page is like a row or a record in a table , the table being the template, and the individual columns being the fields in the template.

[teppo]

@lundy: congratulations, you've nailed it. That's a very good way to describe it

Of course it's not literally quite like that. Since you've mentioned that you're a beginner, it might be useful to know that there's a lot more happening behind the scenes:

• Each page is connected to a template, which is connected to a fieldgroup and each fieldgroup is connected to varying number of fields.
• Taking things even further, each page is represented as a row in pages table, each template as a row in templates table, each fieldgroup as a row in fieldgroups table, each field as a row in fields table and so on.
• Eventually each row of data you've filled on any of your pages inserts a row in that particular field's own database table, i.e. field_title, where column pages_id identifies the page this particular row is related to and column data contains actual title field content for that page. Field tables can have varying amount of different columns, but this is the basic setup anyway.

Understanding how things are connected at database level IMHO makes them more obvious on the front end side, but for most use cases (and most users) knowing what you already know is quite enough. It's still good to realize that there's a lot more to a system like this than just simple database table with couple of columns and rows

Each question as it's own page does seem the most obvious solution here. Of course this still depends a lot on your specific needs; are these questions just simple question-answer type of things, how much data is there going to be for each of them, do they have comments or votes etc. Ryan recently published an events field, which could also easily be modified to accommodate very simple question-answer-pairs.

[lundy]

@teppo, thats a very good explanation of how processwire works.  I can understand the front end much better now.  Thanks