Managing non-page data

[retro]

Hello everyone,

I just started using ProcessWire, and I must say I'm pretty impressed with it. I managed to add it to an existing site in a few hours (http://shaolin.hr) without any problems, so kudos to you guys.

Now, I have a need to work on the site that has some functionality that doesn't really fit in the page paradigm. It is a site for the football league, and while I will manage content with ProcessWire, there is data I need to manage that is strictly relational and I need SQL power for statistics, leaderboard and so on. These are the models I should handle:

• Leagues
• Teams
• Players
• Games
• Seasons

I should be able to get a leaderboard for league per season. I should have a goalgetter leaderboard (per league), etc..

I think I might fit this data in the ProcessWire pages, but I'm concerned about stats and performance of these calcualtions. If this is not really a fit for the ProcessWire, is there a way I could create custom admin section where I could somehow reuse frontend widgets while using some other ORM for the data model? 

[Wanze]

Hi retro and welcome.

I think ProcessWire Pages are perfect to manage your models + you can use the Pw API for your queries.

With the Page fieldtype, you can model all relations you need (1:n, n:m). Pw is really fast and as long you don't query "huge" data i think performance is not a problem. There's also the MarkupCache module to cache generated markup for a given amount of time in addition to the Template-Cache. (and of course the new ProCache module)

Another advantage: You already have the admin interface to create/edit/delete data. Also you are more flexible if you need to extend fields.

Is the site already online?

However, if you decide to use custom tables, you can use a 3th party ORM or Pw's mysqli:

//in Template
$db->query("...");

//in Module
$this->db->query("SELECT * FROM players")->fetch_array();

For the admin, you could create "Process" modules. These are sites that run in Pw's backend.

I'd go with the first solution. Just ask if you have questions how to structure your Pages

[diogo]

I agree with Wanze. Just think of the pages tree as an easy to query database, and of the page fieldtype as the foreign keys. Pages are not always pages.

[retro]

I'll definitely try to use processwire for managing the data. Thanks

[SiNNuT]

I never got around to actually working on the project but maybe this thread can be of some interest: http://processwire.com/talk/topic/1486-modelling-data-in-pw-page-relations/

Also if you go with pages take a look at the db structure of templates, fields etc. The way you use fields can have implications should you want to use certain sql queries/functions. http://processwire.com/talk/topic/2047-group-by/

[Nico Knoll]

You could create a template called "data" with just an title as "key" and an "value" textfield and create them as subpages of "admin". That's the way I handled month names and stuff like this.

[ryan]

I think I might fit this data in the ProcessWire pages, but I'm concerned about stats and performance of these calcualtions.

How much data are you talking about? What kind of queries would you be performing on the data? The vast majority of things you can do from ProcessWire's API, but we also don't try to cover the entire scope of MySQL either. So I'd be curious to know what kind of statistics you are pulling out of the database currently, before recommending whether you should use pages for the purpose. 

If this is not really a fit for the ProcessWire, is there a way I could create custom admin section where I could somehow reuse frontend widgets while using some other ORM for the data model? 

You could absolutely do this. Creating a custom admin section is as simple as: a) creating a new template, then creating a new page in admin that uses that template; or b) creating a new Process module, then assigning it to a new page in admin (that uses template 'admin'). The admin itself is nothing more than a web app created in ProcessWire… you can extend it in the same way you would your own site.