I have a simple social network project going and I would like to add a simple recommend this user profile function. A logged in user can 'recommend' a user once - its just like the 'This ansewr is helpful/not helpful' buttons here on posts in Stackoverflow. I want a simple table design to implement the exact idea - any tips?
A user can recommend any user ONLY once and likewise each profile would have a simple tally saying - this user has been recommended X times. Its just a number nothing real fancy or so...
[Recommender, Recommendee, Recommendation] PK being the first two fields ?
Since it is a many-to-many relationship, you will need a separate table- unique id (auto increment), recommender (userid), recommended (userid).
Related
I'm building a simple login/registration feature, and I'm having a little trouble.
The issue is this, the user system I'm designing is supposed to accommodate different types of users, like (Blue users, Red users, Black users etc). So I was considering porting their different user data to separate database tables, and even giving them separate registration pages, because the content they would view on the site would vary depending on their color.
For example:
Blue Users:
INSERT 'username' INTO `blue` where...
Red Users:
INSERT 'username' INTO `red` where...
But I want to know if there's a way to log them into the site from the same login page without resorting to sending them to different pages when they want to login. I tried the following:
"SELECT `id` FROM `blue`,`red` WHERE `username`...
but it did not work, so I'm asking if there's a way to register the different user types on the same page and log them in on the same page while still giving them their different content.
One problem is probably that the "id" value is an auto-incremented primary key, right? Therefore it would be unique to only the table that they are in, but not over all tables (blue, red, black)
You would then always have to make sure to have unique usernames and ids over all groups or let them select what group they are when they log in and then only load data from that table.
If you have already solved the uniqueness problem, you should be able to simply use the union querys already suggested by other users. You can't use blue, red, because that is short for blue JOIN red, which of course will only result in data where columns with the same name are equal across blue and red.
Assuming that the user can be just in one table, you could use UNION...
SELECT id FROM blue WHERE username...
UNION
SELECT id FROM red WHERE username...
... but as a piece of advice, if user info is the same for all, you better have one table for usertypes and another for users, and link them with a foreign key...
USERTYPES TABLE
id_usertype
usrt_name
USERS TABLE
id_user
id_usertype (this should be a foreign key)
usrname
I hope it helps.
I've posted a few questions on here and have gotten very great help and support. I'm still fairly new to programming and I'm putting together what I thought would be a simple website for the company I work at. I apologize in advance for my lengthy post/question, I just want to be thorough and clear in what I'm asking. My question is more of needing some help getting pointed in the right direction of how to get started and some best practices to be aware of. What I'm working on right now is to create a system where a user can submit a questionnaire/online form to inquire about a specific product (in this case it's a hard money loan product). The way I am planning on setting it up is to have a database with multiple tables (users, user_info, loan_app, property) and connect these together by referencing each other. I've read about table joins and I understand them conceptually but I have no idea how to implement in practice. I've had a hard time finding actual examples.
Specifically, this is what I am doing and how I am thinking it should work (correct me if I'm wrong or if there's a better way to do it):
1- the user (aka the borrower) signs in to the website. The user log in system references the user table where things like first name, last name, user name, password and user ID are stored. I have included an "active" column in this table so that when a user logs in the condition for them to get into the website is that the username and password match AND the user is activated. This way we can control on the back end certain user accounts access. I have this part working.
2- when the user registers, they only fill out the information that creates a new record in the "user" table. I have created a second table called "user_info" that will contain other data like home address, phone number email etc. But I need to be able to associate the correct record with right user. This is my first issue to wrap my head around. My thinking behind doing this instead of simply putting all this information in the user table is that for one, I might keep adding to that table and make it very big, and two for security reasons, I would like to keep the information separate. I don't know if this thought process has any merit to it though. Again, that's why I'm posting this here.
3- The user, once logged in, clicks on a button on their home screen/dashboard that will take them to the loan "pre-approval application" form, which is the questionnaire. On this form their basic information will be echoed/posted from the "user_info" table to pre-populate certain fields like first name, last name, email, phone number, address etc. So going back to #2 making sure I can associate the user with the correct record in the "user_info" table is critical. THEN, there are additional fields that the user has to fill out in order to submit the application/questionnaire. These form fields will create a new record in the "loan_app" table. This table will have a loanid column that is the primary key for that table, and an auto generated/randomized 6 or 7 digit loan number (loannum). The loanid will be a hidden value but the loan number will be like a reference number that is associated with the loan for the life of it and used for later accounting and recording purposes internally, whether or not it actually becomes a loan. The loanid, I'm assuming here, is the Foreign key in the "user" table and the userid is the Foreign key in the "loan_app" and "user_info" tables correct? If so, how do I incorporate being able to simultaneously associate all these records when the loan application/questionnaire is submitted? My thought would be write individual php scripts that does each of these things separately then have a "master" php that includes all of those individual ones that is placed as the form action associated with the submit button on the form.
Thanks for taking the time to read through this. I'd really appreciate any advice or reference material that I can read up on to learn more about this stuff. My job has a pretty crazy schedule and I travel a lot so I don't have the time to take actual classes to learn this stuff formally. I'm pretty much doing this as I go.
Also, I'm using MAMP with mysql, not sure if that helps any or not...
The user table's primary key userid can be the primary key of the user_info table as well, since each user will have only one user_info record, right? A foreign key constraint is good to ensure only valid userids get recorded in user_info.
The loan_app table can contain a denormalized relationship from loanid to userid so that each loan application is associated with a user. Again, use an FK constraint for integrity.
Don't include loanid in the user table - that would mean each user has a relationship to a single loan application. You already have the one-to-many relationship you need in the loan_app table.
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 am implementing a simple database system. Basically is a simple social network, everyone has his own dashboard, where you can post some random text. The problem is that I want a privacy level, I mean I want that somebody is allowed to browse only some profiles. And I'm deciding who can watch what.
The question is: How can I do that?I have to work with relation in the database or what?
Thanks for your time.
S.
What you are looking for is called "Access Control List" (ACL): Check out Nettuts tutorial on implementing an ACL: http://net.tutsplus.com/tutorials/php/a-better-login-system/
Create a secondary table where you keep who can access what. If in the main user table you have and id or something (preferably indexed) (like you should). Just make a 2 column table with id and view_id or something (both foreign keys and togeder should form a pk). And... you read from it.
Most probably you would want to set a table for your privacy like
id type
1 View All
2 View None
3 View Something
then on your table where users can be found you could call the type
user_id privacy_id
1 2
2 3
4 1
where privacy_id is the id of your privacy table, something like that.
In my database are 2 tables: "books" and "users". I'm displaying all the books on a page and would like the option for a user to click a little link "I've Read This", similar to Facebook's Like function with statuses. The user could click that they've read the book or unclick to "unread" the book. Other users logged in could also see who has read what. I'm questioning my approach and would like to get feedback on other directions to take for something like this.
What I had in mind was to have a field in the "users" table, maybe something like "books_read", in which I would store an array of values (book_id's). On the frontend where all the books are displayed, I would query the "books_read" field and if a value matched the current book_id, then underneath that book would be something like "User X has read this".
In short, I would store an array of "book_id"s in the "users" table to collect what books each user has read. I would pull this array and compare IDs to each book queried, and if there is a match, output that the user has read that book.
Am I missing something or maybe not looking at a cleaner approach?
In a RDBMS such as MySQL, it's rarely ever a good idea to store lists in a field, especially when you know you will be looking for specific pieces in the list later on. The database can not take advantage of an index by doing that.
Instead, you should make an additional table that links users and books read. Optionally, you could call it *users_books* and move read in to its own column.
users_booksread
-----------
user_id
book_id
Create a separate table, perhaps called book_read.
In it, for each book a user likes, store the user_id and the book_id.
Then you don't have messy arrays to deal with, everything is normalized, your design will be cleaner, and your database more flexible. Additionally, your user table won't have a bunch of extra crud bolted on to it that will affect performance in unfortunate ways.