How to structure data

[Erik]

I want to build a searchable database like this in Processwire.

https://decon.se/en/adapters/

Now I'm looking for a way to structure this in the backend. 

I started to make a structure like this with pages: 

Adapters->E-drive->Alu Rhab->Netti I (but maybe it's to complex beacause of repeating brand names in the categories.)

Is there a better way with help of tables or repeaters maybe.?

[BillH]

I've no definitive answer, but my thoughts are these.

The data appears to have a clear hierarchy, so if there'll be no complications you haven't mentioned, using either standard pages or repeaters or tables would all be OK as data structures.

When it comes to building templates, all three approaches are more or less as easy as each other.

The approach you choose should thus probably be governed mainly by making things as easy as possible for users.

For the pages on which items are displayed in tables (Netti in your example), using a repeater would get everything onto one page, thus matching the site and making navigation in the backend significantly easier.

Using a ProFields Table would have the same benefits as a repeater, and additionally would give a really clear, neat, compact result. This might well be the nicest option (so long as there's a small amount of budget available to cover the licence).

[Erik]

I did try the "Profields Table" but there is no way to have a "File"column. In need it for the PDF file.

[Jan Romero]

4 hours ago, Erik said:

too complex because of repeating brand names

Yes, that would be very un-databasey. You basically have three entities you care about: Chairs, Brands and Adapters.

At first glance (I may be wrong about this) it looks like each Chair has exactly one Brand and exactly one Adapter. For each Brand there are multiple Chairs and multiple Adapters, and for each Adapter there are multiple Brands and multiple Chairs.

Make three templates, Chair, Brand and Adapter. The Chair template has one page field for a Brand page and one page field for an Adapter page. Now you can structure your page tree any way you like.

If you want your URLs to look like http://example.com/e-drive/netti-i/, put Chairs under their Adapters as children. Now you can drop the Adapter page field and just use the Chair’s parent instead.

If you want your URLs to look like http://example.com/alu-rhab/netti-i/, put Chairs under their respective Brands as children. Now you don’t need the Brand page field.

Assuming the latter, finding all Alu-Rhab Chairs is easy: $pages->find("template=chair, parent.name=alu-rhab").
Finding all E-Drive Chairs: $pages->find("template=chair, adapter.name=e-drive").
Finding all E-Drive Brands: $pages->find("template=brand, children.adapter.name=e-drive").
Not sure about finding all Alu-Rhab Adapters, but if it comes to it, you can just get the page ids with SQL and do $pages->findIDs() on them. Or loop over all Adapters and check if there is at least one Alu-Rhab Chair for each one.

[BillH]

Some good suggestions from @Jan Romero.

If you're still interested in exploring the ProFields Table approach, there is actually a possible way of handling the files.

Make a template (without a file) to hold files, and load the files, one per page. Then use a Page type in the Table to hold a link to the relevant page.

The added complexity of this approach might make it unsuitable, but you may be able to think of a good way of arranging things. And on the plus side, you can easily add extra data fields to the files (dates, source, etc) if that's useful.