I am building a friend system in CakePHP for users based on this: Add a friend feature in CakePHP
But I need to add two additional features:
1.) Users need to be able to request and confirm/cancel friend requests
2.) Users need to be able to group friends e.g. Friends, Family, Co-workers etc
Can anyone give me some ideas as to what extra tables I would need and the likely relationships between them and the existing tables.
Also based on that article it seems the relationships are based on which user asked who but I don't care much for that so what would I do to make it so it's just a relationship rather than tracking which user requested the friendship and who is the friended friend?
NOTE: I asked a similar question earlier and had to delete it as everyone mis-understood the question. I am asking a question just like the one mentioned above and hoping to get answers like they have in terms of tables and relationships.
You'll need a field in your relationships database table called confirmed or similar. Basically when a friendship is requested a record is created, but with confirmed set to 0. When the "requestee" accepts the friendship, the confirmed field is set to 1, or if declined the record is deleted (allowing the requester to request friendship again).
To group, you'll obviously need a groups table with an ID and non-unique name field, and a groups_relationships table that has two columns: relationship_id and group_id. This will allow a user to place a friend into a group. You can then query the groups_relationships table with a group_id to find the IDs of friends that a member has placed in that group.
Related
I have users, meetings and comments tables and I want users to be able to post comments on users profile and meetings.
I know how to make one to many relationships for users and comments tables, but I want all comments to be saved in one table and show comments on users profile and meetings.
This is my table structure:
users
id
name
comment_id
meetings
id
name
comments
id
user_id
comment
TL;DR The solution is to use polymorphic relationships which Laravel makes really easy.
IMHO I don't think that a many-to-many relationship will do the job. It would mean that:
a user can post multiple comments. Okay
a comment can belong to multiple user. Weird
a meeting can have multiple comments. Okay
a comment can belong to multiple meetings. Weird
Plus you would likely need two comments tables to achieve that. For instance a comment_user table and a comment_meeting.
The kind of relationship that would fit the most your situation is the polymorphic one. The name can be scary because it comes from ancient greek. But the concept behind the name is very simple. And Laravel makes polymorphic relationships very easy. You will certainly recognize your situation in the example given in the Laravel documentation ;)
While saving comment, also keep a field named model (or anyone you like) to identify users profile and meetings
HTH
I'm looking to create a database for users with multi-level user rights and I don't know how to go about doing this. What I mean is that I want a manager of a business to be able to purchase my product; that person would be given Owner rights, but would also be able to grand additional users under that license--those people would be given Manager or User rights. Each level (as well as my level: Admin, and my staff: SuperUser) would obviously have individual rights/privileges).
What I'm asking, more specifically, is how to set up the database. For example, if my business is a corporate calendar/organizer, the Owner would set up departments, each with a Manager and many Users. What's the best and most efficient way to structure the database? Like, would each user (and each calendar entry) have to be associated with an ID that belongs to that specific Owner account? I'm just a little lost as to what the best way to organize the database to keep everything together, as I will have multiple different Owners with their own company structure under them.
I want to use MySQL and PHP.
I tried to make this as logical as possible. I think I'm making it too hard, but I am sure there is a standard that makes it easier....Thanks in advance.
At the very least every product/object whatsoever needs a foreign_key in its table, as for example the user's id. This is necessary and sets the relation from the product/object with the user.
And then it depends on how complex you want your system to become. An easy way would be to just use boolean columns in the user table, like an admin, an editor column and so on, with only true and false as values. In your code you could then use if and case to check if a user is an admin and show him parts of your app or not. Like a delete link for example. But you could also restrict updating and deleting to people whose user has a true value in the sufficient column.
The more complex route would include other id-fields in the tables which set a relation of something to something else. Like say you want the user to be a seller or a buyer, then you would add seller_id and buyer_id columns to the products table and check if the ids correspond with the user_id. But not "the" user_id, but a different user_id which you saved when the user created the product listing for example. This way you could guarantee, that besides your staff the user who created this thing has rights to edit it, too, because of the product's user_id being the same as his user_id (current user) when he is logged in to your system.
You could do even more complex relations but then you'd have to create another table and save other ids in it which relate certain users with say other users. In this table you save let's say a maintainer_id and a maintained_id, both have values of certain user_ids but this way you could make a relation between objects one user could change, though they belong to others. Or if you're talking of customers so the mainter_id would be allowed to write messages to those people with maintained_id, like if someone is a seller and the others are potential buyers.
I'm having a little trouble understanding exactly what you're looking for. From what I've gathered, it seems you want a database that holds permissions, users, and departments. In this very basic example I've created 3 tables. (assuming one user can only belong to one department)
You could set a foreign key in the users table which links to the primary key in the permissions table. The departments table would have the foreign key of the user_id.
You could base all of the logic on what each permission can do with your queries and application side logic.
(I can't embed images due to not having 'enough rep')
I've done quit a bit of programming with php/mysql on small scale personal projects. However I'm working on my first commercial app that is going to allow customers or businesses to log in and perform CRUD operations. I feel like a total noob asking this question but I have never had to do this before and cannot find any relevant information on the net.
Basically, I've created this app and have a role based system set up on my data base. The problem that I'm running into is how to separate and fetch data for the relevant businesses or groups.
I can't, for example, set my queries up like this: get all records from example table where user id = user id, because that will only return data for that user and not all of the other users that are related to that business. I need a way to get all records that where created by users of a particular business.
I'm thinking that maybe the business should have an id and I should form my queries like this: get all records from example where business id = business id. But I'm not even sure if that's a good approach.
Is there a best practice or a convention for this sort data storing/fetching and grouping?
Note:Security is a huge issue here because I'm storing legal data.
Also, I'm using the latest version of laravel 4 if that's any relevance.
I would like to hear peoples thoughts on this that have encountered this sort problem before and how they designed there database and queries to only get and store data related to that particular business.
Edit: I like to read and learn but cannot find any useful information on this topic - maybe I'm not using the correct search terms. So If you know of any good links pertaining to this topic, please post them too.
If I understand correctly, a business is defined within your system as a "group of users", and your whole system references data belonging to users as opposed to data belonging to a business. You are looking to reference data that belongs to all users who belong to a particular business. In this case, the best and most extensible way to do this would be to create two more tables to contain businesses and business-user relations.
For example, consider you have the following tables:
business => Defines a business entity
id (primary)
name
Entry: id=4, name=CompanyCorp
user => Defines each user in the system
id (primary)
name
Entry: id=1, name=Geoff
Entry: id=2, name=Jane
business_user => Links a user to a particular business
user_id (primary)
business_id (primary)
Entry: user_id=1, business_id=4
Entry: user_id=2, business_id=4
Basically, the business_user table defines relationships. For example, Geoff is related to CompanyCorp, so a row exists in the table that matches their id's together. This is called a relational database model, and is an important concept to understand in the world of database development. You can even allow a user to belong to multiple different companies.
To find all the names of users and their company's name, where their company's id = 4...
SELECT `user`.`name` as `username`, `business`.`name` as `businessname` FROM `business_user` LEFT JOIN `user` ON (`user`.`id` = `business_user`.`user_id`) LEFT JOIN `business` ON (`business`.`id` = `business_user`.`business_id`) WHERE `business_user`.`business_id` = 4;
Results would be:
username businessname
-> Geoff CompanyCorp
-> Jane CompanyCorp
I hope this helps!
===============================================================
Addendum regarding "cases" per your response in the comments.
You could create a new table for cases and then reference both business and user ids on separate columns in there, as the case would belong to both a user and a business, if that's all the functionality that you need.
Suppose though, exploring the idea of relational databases further, that you wanted multiple users to be assigned to a case, but you wanted one user to be elected as the "group leader", you could approach the problem as follows:
Create a table "case" to store the cases
Create a table "user_case" to store case-user relationships, just like in the business_user table.
Define the user_case table as follows:
user_case => Defines a user -> case relationship
user_id (primary)
case_id (primary)
role
Entry: user_id=1, case_id=1, role="leader"
Entry: user_id=2, case_id=1, role="subordinate"
You could even go further and define a table with definitions on what roles users can assume. Then, you might even change the user_case table to use a role_id instead which joins data from yet another role table.
It may sound like an ever-deepening schema of very small tables, but note that we've added an extra column to the user_case relational table. The bigger your application grows, the more your tables will grow laterally with more columns. Trust me, you do eventually stop adding new tables just for the sake of defining relations.
To give a brief example of how flexible this can be, with a role table, you could figure out all the roles that a given user (where user_id = 6) has by using a relatively short query like:
SELECT `role`.`name` FROM `role` RIGHT JOIN `user_case` ON (`user_case`.`role_id` = `role`.`id`) WHERE `user_case`.`user_id` = 6;
If you need more examples, please feel free to keep commenting.
I'm building a private social network with Yii that will have "comments" all over the site - in Profiles, Events pages, Group Threads, etc. When a user makes a post, they will be able to select the visibility of that content as:
Anyone
Registered Users Only
Friends Only
Custom (specific list of friends)
I'm trying to figure out how to model this for speed. I've considered using MySQL for writing the setting into a binary "is_secure" field in the Comments table - if it is true, then go to a table with three columns: comment_id, user_id, and group_id. Groups (group_id) would be for groups of users - Registered Users, Friends. Custom would make one row for each user that is selected (user_id).
This table will get huge (perhaps several dozen rows for each comment), so I'm wondering if using NoSQL is worth considering here for retrieval only, or if there's a better way to model this.
Thanks so much!
Similar question to database "flags". Search for related SO questions.
Instead of an IF true/false with the is_secure field, just add 1-bit fields for read_all (anyone), registered, friends, custom. Add another table which holds the custom list would have comment_id (from the previous table) and friend_id (multiple rows). That way, in a single query with a LEFT JOIN on custom_friends_list_for_comments you can determine whether or not to show the page to a user. Optionally, custom could be a comma separated list (char field) but size limits might be an issue. Assuming 3-letter friend ids with a comma, each 255 char field can have 64 friends.
I am developing a social network for an intranet, and I came across a problem [?]. I have the entities User and Business as main entities of the network.
Note: A Business does not have, necessarily, a relationship with a User.
Following this idea, I have a group table, and a group can be created either by a user or by a business, there comes a question, how can I make the author field in this table?
I did the following, I created a table type, with the following data:
id | name
1 user
2 business
And my table groups like this:
id
name
description
tid (FK -> type.id)
author (INT)
Thus, if a group has a tid equals to 1, means that the author is referring to a User, if it have tid equals to 2, it is referring to a Business.
What do you think about this implementation? It is correct?
What can I do to improve it?
I'm using PHP 5.3.6 (Zend Framework and Doctrine2) + MySQL 5.1.
Per request:
The terminology for this is "polymorphic". Bill Karwin had a good answer that I can't find at the moment about it. From a database design perspective, I've been told the logical model term for this is an "arc" relationship. Either way, I see no issues with what you posted, other than supporting multiple authors.
The bad thing about this is that you cannot use the foreign key constraints to check and verify your data if you do this.
I would recommend using 2 tables instead. one to store the relationship between user and group, and one to store the relationship between business and group.
This will allow you to use all the fk benefits like cascading deleted when the group or business or user is deleted.