CODEWITHSUNDEEP
phpmysqlreporting
bfavaretto
bfavaretto

Reputation: 71918

MySQL custom reporting strategy

We have an PHP/MySQL application where the users can create their own "databases", which can become quite complex. On MySQL, it's structured as a set of property tables, with columns like record_id, field_id and field_value. I'm well aware of the pros and cons of such structure, so please consider this is not changing.

We already have a custom advanced search system where users can query those databases by combining criteria from any field, using boolean operators between and within fields.

Now we have to implement a reporting feature where they'll be able to craft their own reports. This might include multiple sets of data on a one to many relationship.

For example, consider a "People" database where each person may have multiple contacts and multiple addresses. With our custom search, it's easy to list all people born in the US, for example. But I also want to display all contacts and addresses for each person on the resultset.

I can see two possible solutions:

  1. A single SQL query with multiple JOIN statements to fetch all data. In this case I may have multiple rows for each person, depending on how many contacts and addresses they have, and I'd have to deal with that on the PHP loop that displays (or organizes) the results. I'm afraid this can get too complex, considering a report may have an unlimited number of one to many blocks of information (on my example, I have only two, addresses and contacts).

  2. For each person, run 'n' additional queries, one for each block of one to many data. On my example, that would be one query for the contacts, and another one for the addresses. That approach can lead to a huge number of queries to be run to build the whole report.

I know both approaches have their downsides, but is there a "recommended" way to go on situations like that?

Upvotes: 0

Views: 625

Answers (1)

Dan
Dan

Reputation: 1888

This certainly depends on the amount of queries you think you will have to make to retrieve all the data. From a performance standpoint it is recommended to perform the large join as it can be processed far more efficient than multiple small queries.

You will find that large reports will take longer using your second approach than using your first approach.

Upvotes: 1

Related Questions