title: Running sql queries as one sql script (with inner joins) vs more than one script while manipulating them in an array
body: <p>I have trouble understanding specific things and I will share my experiments: </p>
  
  <p>From what I have learned from my previous jobs where the directions from the CEO included: all mysql queries must include parameters I need and query them all at once to get the accurate data, am I right? So this will do a perfect job if I had an e-commerce store where I load 10 items for a query. My conclusion here is - this will work great for pages where I don't need to load a lot of data all at once. doesn't matter how big is my database. (considered: <strong>good practice</strong>) </p>
  
  <p>I have a website where I have to return a (long, big, heavy, hell of a) CSV report. I wrote all the queries required with INNER JOINs - 
  <strong>BUT</strong> this time my database includes millions of rows, and my report loops 50,000 times (through each customer I have), and uses INNER JOINs to gather data out of 4~6 tables which include millions of rows each. and in some even does some calculations. All the system is, off-course, OOP, so each object of a single user (which is a query by itself). 
  So my code has a lot of small queries to the database requesting data for each users, and while looping, having around 4~6 big-INNER JOIN queries. This took a few minutes to run. </p>
  
  <p>I thought it doesn't make sense so I decided to experiment with it. 
  I decided to separate everything, and not to use everything as an "object" but rather get all data at once from the table, without any joins, and manage it via PHP. So I got all users with the relevant data to 1 $users array. then got more data from table A. then from table B. organized table B. got data from table C. made calculations on table C. ect'. Looped again while matching my data to one final array, and outputting to a csv. </p>
  
  <p>AND THIS TOOK LESS THAN 1 minute to run!</p>
  
  <p>Instead of eating memory out of my database, it did affect the CPU. and after re-writing my code for more efficiency - it took less than 30 secs. and didn't have any CPU bumps. </p>
  
  <ul>
  <li>If all my code is based on OOP and this way of "direct" scripting works faster: Is that ok to continue with it for specific big heavy outputs? (<strong>in terms of "good or bad" practice</strong>). </li>
  </ul>
  
  <p>PS: I would have used summary tables but that's not what the CEO wants for now. </p>
  
  <p>PS2: Tables are indexed properly.</p>