Ideal way to manage DB's table.users for future development?

Question

Need to mention first that i'am a newbie in PHP/MySQL. I would like to hear from you, from your experience, what's the best way or approach to deal with a table rows such as tbl.users for future development and compatibility with other features on web application ?

Currently, I have a tablename users like shown below:

id  catid   firstname   lastname    username    email   password    status  image
14  21      Joe1        Doe         joe1.doe    jd@m.cc sha512ed    1       pic.jpg
15  17      Joe2        Doe         joe2.doe    jd@m.cc sha512ed    1       pic.jpg
18  22      Joe3        Doe         joe3.doe    jd@m.cc sha512ed    1       pic.jpg
33  20      Joe4        Doe         joe4.doe    jd@m.cc sha512ed    1       pic.jpg

Now when I'm done with users, I would like to create an basic e-commerce with products, and clients, etc... And here comes the question, how should i work it out without need to recreate a tablename clients ?

Would be it clever to add a new column to tbl.users such as attributes and store some attribute there to extend the functionality such as client = 1 or something like that ?

So it will become like this:

id  username    ... attributes
14  joe1.doe    ... rememberme = 1, client = 1
15  joe2.doe    ... rememberme = 1, client = 0
18  joe3.doe    ... rememberme = 0, client = 0
33  joe4.doe    ... rememberme = 1, client = 1

Meaning that user.id = 14, 33 will become clients, and will be displayed appropriately in e-commerce component ?

If it's ok, how should I store that attributes information ? I guess the way I made it is not right.

Answer 1

i learned that its better not to mix tables, i mean if you have users table, dont add cart stuff info into it, will make it hard in the future to read the table, and you wont understand why you added that info into the users table.

the question is what clients are? non users, just visitors or users as well? if they are users, you should make clients table, with unique id, user_id, client_id, very basic table that will allow you to get the number of clients that user have, and in the future you can add more columns into the table like, items_bought and much more, you should do that if a user will get multi clients, witch i think is the case.

but if each user will have 1 client (i dont think its the case), you can add column into the user table client_of but then you can't store multi clients, only one.

so for the future, dont mix tables, each "theme" should have its own table, in my opinion of course.

P.S you have many options when you have 2 tables, so dont add the same attr to both of the tables, add all the info of the users to the users table, if you need the user info of a client, get his id from the client table and then get the info from the users table, but if you need an info that only clients need, then add that attr to the client table.

edited: quick example :

users table:

`id`    `first_name`    `last_name`    `username`    `password`    `date`
`1`     `alex`          `maya`         `alex.maya`   `pass12`      `yesterday`
`2`     `bob`           `smith`        `bob.smith`   `pass43`      `today` 

the client table:

`id`    `user_id`    `client_id` 
`1`     `1`          `2`
`2`     `2`          `1`

this tables says that alex bought from bob and bob bought from alex, lets say i'm bob, and i want to see the info of the user that bought from me:

$sql = "SELECT client_id FROM clients WHERE user_id = {$user_id}"; // output = the id of the users who are his clients.

`

Answer 2

First, I recommend you read a bit more about the design database, particularly on how to obtain best tables by normalization. You will see that you should first design your database graphically, making a simple diagram with entities and relations between them. As object-oriented programming, you want to have more general tables with minimal data common to several types, for example a person table which you can then specialize in Customers, Vendors, Employees, etc., if your design requires it. The next step is to ask how these entities are related, that way you can see that you need a new table for the relationship or simply add a unique ID in the other table.

Here I leave a link to learn the issues that I mentioned to you earlier: http://www.sqlcourse.com/index.html