Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Tim-KH's avatar

Best practice to store and output data

I want to have a simple show view for my users. Here I want to output data like this:

Contactinformation: E-Mail: XXXXX, Skype: XXXXX, Phone: XXXXX

General Data: Last Online: XXXX, Birthdate: XXXX, Website: XXXX

Extra informations: Place of residence: XXXX, Comment: XXXXX

I have thought about three different way to achieve this.

  1. Just store all data that belongs to the user in the user table and call it in my view like that $user->email etc...

  2. Store all information in the user table and use my controller to create three different arrays with the correlating data and run a those in a foreach in my view.

  3. Store the Contactinformations, general data and extra informations in a seperat table and connect it with the user table with a one to one relationship.

All these would have the same effect but I would love to know what the best approach to such a thing is.

0 likes
1 reply
burlresearch's avatar
burlresearch
7 years ago
Best Answer
Level 40

Seems you're having some trouble trying to figure out: "what is a User in your context"

When crafting a database - you have to make some decisions about what your data means to you - then you can worry about the best way to store it.

With what you've given - there are some hints you've given. I think the way I like to think about some of your issues. When modelling a database:

  1. When you're talking about 1-1 relationships of tables, why are you making another table. There are good reasons to do this, sometimes. but often any 1-1 relationship of a table element really just represents a property of that element - why not just put that property on the same table? For a user, these are really properties that could easily be stored on the same table {Last Online, Birthdate, Website, Place of residence, Comment}
  2. If a "User" in your system could have multiple options, then I would think that's no longer a property of your user, but a relationship. So, {E-Mail, Skype, Phone} might be candidates for an alternate contact table where a given user could have multiple associated accounts. So maybe you want to break those out.

It's up to you how you model it, but try to keep things simple as possible, and don't be afraid to change them later, if you think your requirements merit a change.

Please or to participate in this conversation.