If you do a query like SELECT * FROM users LEFT JOIN usersmeta ON users.userid = usersmeta.userid
Then your results should look something like [userid = 42, email='bbb@mail.com', metakey='city', metavalue='Huntsvile'],
If youāre on MySQL 8, have you considered a JSON field for the user meta data?
That you way you can still query the one table, obtain all primary data and an additional key that contains all meta data as a JSON string. Run json_decode over it and you get an array.
The MySQL JSON type even allows to query within JSON fields.
What if a user has a metakey called age or school or anything else?
This is just a general design issue. What if questions can be very dangerous and can result in unnecessary code and slower development. What if users never us this meta capability? If you know for a fact that they will then sure. If not then design for what you do know.
You also need to think carefully about the rest of the meta implementation. Suppose the user does want an age property? Now what? How exactly are they going to do that? A user friendly interface for adding properties can be challenging. What will the rest of your application actually do with this custom property? Not to mention the fact that age is a number and not a string. Does that matter? Should you add a metatype to your table?
That was a perfect answer thanks alot but if you read my initial you will notice i never wanted to loop the second time.
because i have already looped the usermeta separately to have it look like the way i posted it.
So this will sum all the user meta data into on single array.
Then i can actually use the $data array keys to merge it probably in the second foreach looping but I was looking for something handy instead of a second looping.
The user can have many options to add to the metakey and we have limit the number of metakey keys that can be added but we donāt limit what the metakey is called.
example you have a limit of 100 rows to define yourself, so what ever you choose to call yourself must come as a single row or metakey with its value.
So sorry Sir, you where not being ignored, just that you stayed focus on archiving it using SQL JOINS even though I am so eager to see such results but i noticed it canāt be archived that way because the metakey can be assumed to be dynamic and not fixed.
So hard coding the query has already limited the fun of having each user name their own metakey and then assign a value to it.
Note: we have a limit of 100 rows per user but the name of the metakey is solely dependant on the user.
Why canāt you just do a simple LEFT JOIN and structure the results into a structured data array.
You manually define the 2 or 3 fields from the users table, i.e.