I have a forum website that I'm building myself. I'm planing to add group section into my website.
Users will be able to create groups. And manage by themselves. and then the creator should add moderators to the group.
How should I store this moderators? Should I create new table like this:
group_moderators
ID - GroupID - UserID
or should I directly insert into group table
ID - GroupName - Moderaters
1 - Tech - 5, 7, 9 (These are User IDs) then I can separate them with PHP.
It depends on your plan:
if you are planning to have multiple moderators per group then you
have to create a new table for moderators
if you are planning for only 1 moderator for each group then you can add a new column to the group table
UPDATE
Multiple IDs in 1 field is not a good idea at all, it will cause a lot of headache if you want to select, update, join, delete moderators.
First option because it'll be easier to delete or update the mods and it''ll be eaiser to update the table if you intend to give different powers to different mods in future ..
For Ex
ID - GroupID - UserID - Power
1 14 1 Mod
2 14 3 Super-Mod
Related
I currently have 10 almost identical tables, 1 for each section of content in my app. There are no queries in my app that access more than 1 of these tables at a time.
Option 1
Create a single articles table having all fields the multiple tables have in common. Add a new section field indicating the old table name.
Reduce each of the 10 original tables fields to only the 4 or 5 fields that were unique to that section.
Add a foreign key pointing to the original record in the articles table.
Rename the 10 tables to start with the prefix "extra_".
Create 10 views that inner join the articles table to each extra_ table.
These views would have the same name as the original 10 tables.
Thoughts:
Since the resulting views would contain all the fields from the original there would be very little existing PHP/SQL code that needs updating.
If I can't INSERT, UPDATE, or DELETE against the views I'd need to make many changes to existing PHP code.
Adding to the articles table a new field and making it available in the views requires recreating 10 views.
Removing from the articles table a field which was used in the views requires recreating 10 views.
... other benefits or drawbacks?
Option 2
Keep the current 10 tables, create a view that UNION ALLs all the tables together.
Thoughts:
Changes to any of the 10 tables requires recreating only 1 view. Zero changes needed to existing PHP code.
... other benefits or drawbacks?
Option 3
Do everything in PHP. Make an array listing all the tables and which fields are desired from them. Dynamically generate and search the big UNION SQL query with PHP.
Anyone have a better suggestion or advice on the options proposed?
I was about to create my tables when I noticed, sh!t. I have no field to group similar entries (that is the main purpose of this table lol). The idea is, there is a family that has signed up and I want to group them. So when I pull out data, I can assign prices to the family as a whole.
gp_ID customer leader_Of_Group
1 Turk yes
1 JD no
1 Sarah no
1 Felina no
2 John no
2 Manny no
2 Jaden yes
*note - simplified table for readability
My problem is, I don't know how i'm going to achieve the gp_ID. I am confident primary keys don't allow duplicate values so, i'm stumped at the moment.
The gp_ID will be entered automatically, I just don't know how to increment after each family has signed up. Furthermore, there is functionality where my client can select which passengers to group.
I'm not sure how to go about setting up this table or how to query it in a way that each family will increment appropriately. My only thought so far is finding out the gp_ID based on the latest entry and increment, and even then I don't know how to go about doing that or if i'm on the right track. Also, would an auto increment field be necessary too? Any help/guidance would be greatly appreciated.
You are facing an issue because you really have two entities. One of the those entities is the group and the other is the group members.
Your process for adding members to a group should be:
Add a row to the Groups table. This would have an auto-incrementing id.
Add rows to the GroupMembers table, identifying the group using the previous id.
Voila! The groups will be well identified. The Groups table itself could have columns such as:
GroupId (auto-incremented id)
Name for the group
Creation date
Leader_MemberId
The latter would be a way of ensuring that each group has exactly one leader, without having to write a trigger to enforce this constraint.
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.
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.
`
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
I have a MySQL database with a growing number of users and each user has a list of items they want and of items they have - and each user has a specific ID
The current database was created some time ago and it currently has each users with a specific row in a WANT or HAVE table with 50 columns per row with the user id as the primary key and each item WANT or HAVE has a specific id number.
this currently limits the addition of 50 items per user and greatly complicates searches and other functions with the databases
When redoing the database - would it be viable to instead simply create a 2 column WANT and HAVE table with each row having the user ID and the Item ID. That way there is no 'theoretical' limit to items per user.
Each time a member loads the profile page - a list of their want and have items will then be compiled using a simple SELECT WHERE ID = ##### statement from the have or want table
Furthermore i would need to make comparisons of user to user item lists, most common items, user with most items, complete user searches for items that one user wants and the other user has... - blah blah
The amount of users will range from 5000 - 20000
and each user averages about 15 - 20 items
will this be a viable MySQL structure or do i have to rethink my strategy?
Thanks alot for your help!
This will certainly be a viable structure in mysql. It can handle very large amounts of data. When you build it though, make sure that you put proper indexes on the user/item IDs so that the queries will return nice and quick.
This is called a one to many relationship in database terms.
Table1 holds:
userName | ID
Table2 holds:
userID | ItemID
You simply put as many rows into the second table as you want.
In your case, I would probably structure the tables as this:
users
id | userName | otherFieldsAsNeeded
items
userID | itemID | needWantID
This way, you can either have a simple lookup for needWantID - for example 1 for Need, 2 for Want. But later down the track, you can add 3 for wishlist for example.
Edit: just make sure that you aren't storing your item information in table items just store the user relationship to the item. Have all the item information in a table (itemDetails for example) which holds your descriptions, prices and whatever else you want.
I would recommend 2 tables, a Wants table and a Have table. Each table would have a user_id and product_id. I think this is the most normalized and gives you "unlimited" items per user.
Or, you could have one table with a user_id, product_id, and type ('WANT' or 'HAVE'). I would probably go with option 1.
As you mentioned in your question, yes, it would make much more sense to have a separate tables for WANTs and HAVEs. These tables could have an Id column which would relate the row to the user, and a column that actually dictates what the WANT or HAVE item is. This method would allow for much more room to expand.
It should be noted that if you have a lot of of these rows, you may need to increase the capacity of your server in order to maintain quick queries. If you have millions of rows, they will have a great deal of strain on the server (depending on your setup).
What you're theorizing is a very legitimate database structure. For a many to many relationship (which is what you want), the only way I've seen this done is to, like you say, have a relationships table with user_id and item_it as the columns. You could expand on it, but that's the basic idea.
This design is much more flexible and allows for the infinite items per user that you want.
In order to handle wants and have, you could create two tables or you could just use one and have a third column which would hold just one byte, indicating whether the user/item match is a want or a need. Depending on the specifics of your projects, either would be a viable option.
So, what you would end up with is at least the following tables:
Table: users
Cols:
user_id
any other user info
Table: relationships
Cols:
user_id
item_id
type (1 byte/boolean)
Table: items
Cols:
item_id
any other item info
Hope that helps!
I have a table that holds user information. One of the columns holds the position of the user in the game they are in.
When a game is being created, I need to update the positions of the users of each team.
Here is an example:
Game id : 7
Team 1 users : 1,2
Team 2 users : 3,4
team1_position : array(1,2)
team2_position : array(13,14)
What I want to do is update the user table using the array of positions in the SET area.
My goal is to be able to update the users without the need for their id (I have different size game boards, so I have multiple position arrays for each board size)
How can I do something like this:
UPDATE user
SET position='(team1_position)'
WHERE game = '7' AND team = '1'
I feel like it would be a waste of resources to select all the id's of each team and update them separately.
I have a hard time understanding what you are trying to do, better explanation would be nice. From what I understand you are selecting data from tables in order to update other tables. Have you tried using an "UPDATE .. JOIN .." query? This should allow you to update multiple rows from one table based on associative data from another table.
For example
UPDATE user
JOIN game ON
user.id=game.id_user
SET user.position=game.team1_position
Obviously this wont work with your code as I have very little info to go on, but that should give you an idea of what to go with.
Sorry if I'm totally off in understanding your problem, as said it's a bit hard to understand your exact issue based on what you've given us.