Subpages vs Page Field for Performance

[huseyin]

I am sure this asked already but i could not found a clear answer.

Assume i have a list of 1000 Projects. Each project has 250 tasks.

Should i create;

1 - 1000 project pages and a Tasks parent page with 250.000 tasks subpages (Page Field connection between projects and tasks)
or
2- 1000 project pages and 250 subpages for each project page

In total there will be the same amount of pages only the structure is different.

Which one is better for better performance?
With the first approach i would make a find request to 250000 pages with project id filter for each project
With the second approach i would list only 250 subpages for each project.

So it seems to be better performance with the second one. Is this right?

 

[dragan]

I'm not quite sure about the setup...

11 minutes ago, huseyin said:

Each project has 250 tasks

Does each project have exactly 250 tasks? Or "can have up to 250 tasks"? Is each set of 250 tasks tied to just one single project?

Where or how are these tasks defined? Are they "global" (several projects can define one or more of those 250 tasks) ?

If the "tasks" can be used (selected) globally from a set list of pre-defined tasks for each project, then I'd go for page-reference fields. No need for sub-pages.

Perhaps you could describe a real-life usage example to get a better idea of the whole scenario.

 

[huseyin]

It is only an example.

1000 peojects have 250 tasks each and no one commen.

The question is 

When i list one project with 250 tasks which approach is better for performance. 

1 - have a find with parent where pool is 250 pages large

Or

2 - have a find with project id page field filter where the pool is 250.000 pages large