I am working on something smalland was thinking of making a good notification generator like facebook does Mainly I want how the the tables might look. How to make updates and all the nessecities and cautions i should have Thanks
I have users as they upload images comment like a persons profile I want the person whose post was like commented or any other action to be notified that this person likes your photo
The way Facebook does it
There's many ways to do it, one of which is to have a column in the table titled new_notification that will tell you if the notification is new(read by the user or not). So, for example, if a person likes another persons picture, in the table that column will have new_notification set to Y. When the user who's picture was liked logs into the website, you search for all rows where new_notification = Y do a count and show the number of notifications like facebook does. Once the user has seen the notifications or opened the notification bar, go through that table and set all the rows with new_notification = Y to 'N'.
Yes I agree with #Interstellar_Coder, you could have your post page info stored in one line in a database table, and your like info stored in another table. Reference which picture the person likes by ID.
Table 1 (picture posts):
ID | Picture | Comments | who
1 | (pic data) | my picture | user.name_1
Table 2 (likes):
row_ID | picture_ID | who
0 | 1 | user.name_2
1 | 1 | user.name_3
So in this example you have 1 picture posted by user.name_1, then this picture has been liked by user.name_2 and user.name_3. We know this because of the picture_ID field in the likes table.
You can check in your database who likes picture post with ID=1, and it will tell you who likes it, mysql code example:
select who from likes where picture_ID = 1;
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have a SQL-table for user information and a table for offers. If a user uploads an offer, it gets a unique id, aswell as a "belonging_id" with the users id in it.
Now I want to change an element after the offer is already in my Database. But the only information I have is the user's id. And it is possible for a user to have multiple offers.
So my Question is: How can I call one specific offer with a unique id to Update it?
One solution would be, you can make your table as 3-column table, like this:
+----+--------------+----------+
| id | belonging_id | offer_id |
+----+--------------+----------+
| | | |
id column would be AUTO_INCREMENT and PRIMARY KEY, belonging_id would be user's id and and offer_id would be your unique offer id. This way, you can satisfy the following condition,
And it is possible for a user to have multiple offers.
An example table snippet would be like this:
+----+--------------+----------+
| id | belonging_id | offer_id |
+----+--------------+----------+
| 1 | A | XYZ |
| 2 | A | ABC |
| 3 | A | PQR |
| 4 | B | IJK |
+----+--------------+----------+
Now, you can select a particular <belonging_id, offer_id> pair using the id column value.
Sidenote: If you're planning to use this method and insert records in this table, look at the following links to get last inserted id (pick one as per your extension),
mysqli::$insert_id
PDO::lastInsertId
Please give us your SQL Table schemes.
To help you, I think your request should be something like :
SELECT * FROM offers WHERE belonging_id = id_user
EDIT :
You need to have a unique identifier (something like primary key, or a UNIQUE field) in your table offers if you want to retrieve a specific offer among all the user's offers.
When you insert data in a table, you can retrieve the last inserted id.
For exemple, in PHP (using PDO extension) you can do : echo $db->lastInsertId();
EDIT 2:
Let's suppose the user ends on a page send_offer.php after he sent the offer in the database.
You should then generate a unique link like : http://edit_offer.php/?id_offer=the_id_of_the_offer_just_sent
This unique link should be stored in your table offers, so when the user wants to edit one of his offer, he only has to access your site with this link.
This link should point to a web page where there's a form, in which you'll want to load the data of the offer corresponding to the above link.
A user has multiple offers
You want to edit a specific offer
All you know is the user's identity
What you're asking has no coding solution because it has no logical solution. It's like if I gave you a jar of blue and white marbles and I asked you to bring me a specific blue marble. All you know is the color so without further info there is no way to reliably get the marble I want.
Instead of trying to devise a solution on the server end, turn to the front-end. Figure out how to send info that will uniquely identify the request, along with the userID. For instance, include the offer ID in the request process.php?offer_ID=123 so you can retrieve it with $_GET['offer_id'] and use it in the query.
If you have no way to do it all in one step, you could instead:
SELECT * FROM offers WHERE belonging_id = $userID
Send all results to the front end, with their offer IDs attached
Ask the user to select a specific offer from the matches, and return its ID to the server
SELECT * FROM offers WHERE offer_id = $offerID and process that record
Hi I am in the process of making a website that includes a user registration system for my final year of high school major project. The website stores driving logs for learner drivers. I'm kind of confused as to how I should desgin the database. I have a users table which stores the personal information of each user of the site. However, I would like the user to be able to insert information into another table which would be their "logbook" and this to be displayed on the my account page. Do I need to create a table within the database for each user or is there a way of connecting the tables so that i do not have to.
You do not need to create a table for each user. Instead, add a column in your "logbook" table which will contain and refer to the "id" of the user it's tracking. This will likely be the primary key of your "users" table. Then, to get the logs for a specific user, you would query the logbook table for rows only with at specific user ID.
Furthermore, in a more sophisticated setup, you can add constraints to link the two columns. See http://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
U will not need table for each user...
Just one table will help u out...
The other table where u want to store user logs should only have reference to user I'd that u have created in users table..
Primary and foreign key - relational table concepts
For eg:
Let ur user has
1.userid
2.first name
3.lastname.... And other colums
Then ur userlogbook wala table should have
1.logid
2.userid
3.other columns...
Hope u got it..
You only need 1 table for the users, each user will be a row inside that table.
As you see in this table below, you need a way to be able to track which logbook record belongs to which user. That's done by storing the users ID (or any unique identifier, usually the primary key) to know exactly which user created the record.
-------------- -----------------
| User Table | | Logbook Table |
------------------------- -----------------------------------
| id | name | ...etc... | | id | user_id | date | ...etc... |
------------------------- -----------------------------------
| |
|_____________________________________|
I don't know how your system works, but I assume you know when a user is logged in right? Probably store their id in a session yeah? Well when you're inserting the logbook record, all you need to do is parse through their user ID in addition:
INSERT INTO logbook (id, user_id, .....) VALUES (NULL, $THE_USER_ID_FROM_SESSION, .....)
The above is pseudo code, you'd need to sanitize the input and actually assign the user id to a variable.
Now for fetching the user-specific information, all you need to do is add a simple WHERE clause:
SELECT id,column_1,column_2,... FROM logbook WHERE `user_id` = $THE_USER_ID_FROM_SESSION
The above is pseudo code, you'd need to sanitize the input and actually assign the user id to a variable.
There are a few questions I have, how much reading/writing are you going to be doing to the table? How are your tables set up?
I have a client who wants to have a comment box on each page of her website. The thing is, the website has already been created as a static html site. I've made comment boxes in the past using php and phpMyAdmin, and obviously I'll change each of her pages to .php instead of .html so it'll support my comment box's php code, but I've only ever created comment boxes for a single page before. The website I'm altering now has at least 10 pages that need a comment box, and more will be added in the future.
I like the idea of using a singular database table for all the comments that are submitted on the site (there won't be a high volume). I'm just not sure how to tell the submitted comment which page it's supposed to display on.
I think what I need to do is have the submitted comment store what page it's from in the database, and then I can have a function on each page that looks for all the comments with that particular page's name or id. I'm just not sure how to do the first part where I send in data that identifies the page with the rest of the comment box's data, can anyone point me in the right direction?
Sorry if this a silly question, I'm still pretty new at PHP, thanks!!
you're on the right track with your idea. There are multiple ways of doing it, but a simple solution would be to have a page name field in your database table. when gathering the information for db insertion retrieve the page by putting a hidden field in the comments form, maybe something like...
<input type="hidden" name="page_name" value="<?=$_SERVER['REQUEST_URI']?>" />
then upon fetching comments from the database do a db query like
"SELECT * FROM `comments` WHERE `page_name` = '".$_SERVER['REQUEST_URI']."'";
Always remember to sanitize user information before db insertion!
Whay you need is a tablewith a column that identifies the page you need. For instance:
Table: Comments
---------------------------------
id | page | comment | createdAt |
---------------------------------
1 | 1 | Com1 | 2014-01-01 00:00:00|
2 | 2 | Com2 | 2014-01-01 00:00:22|
3 | 1 | Com3 | 2014-01-01 00:30:00|
4 | 1 | Com4 | 2014-01-01 00:35:00|
Then at the specific page use the column page in your where clause to select only the comments from that page.
For instance:
SELECT comment, createdAt FROM comments WHERE page = '1' ORDER BY createdAt DESC
The ORDER BY will rearrange the order with the newest on top.
When posting to the database insert the page identifier aswell.
INSERT INTO comments (page, comment, createdAt) VALUES ('1','this is a comment', NOW())
Get it?
This is a followup to a question I posted a few days ago.
basically, I have a site with six links. In order to access the site, users must log in using LDAP authentication. When they do this, I grab some of their account credentials (username, firstname, lastname), and store it in a PHP $_SESSION variable.
That works; the user can log in, and the session data is being stored successfully.
Now, I want to set up a way to track which links have been clicked by what users. Basically just store a time stamp in the database of when they clicked the link. I want to be able to see who has (or has not) clicked each link, and when.
Can I do this in a single table / would that be a bad idea? I was thinking setting up the table like this:
TABLE (each bullet indicative of a column)
auto-incrementing ID
user account name: abc1234
user account first name: John
link 1: Last Accessed 5/2/2012 at 4:15PM
link 2: NULL
link 3: NULL
link 4: Last Accessed 5/1/2012 at 2:20PM
link 5: NULL
link 6: NULL
basically the above would say that "John" had only clicked the first and 4th links. The rest are null because he has never accessed them. If he were to click #1 again, it would overwrite with the more recent date/time.
Can I do this in a single table? or will that create complications? I feel like the thing I will have the hardest time with is checking to see if the user is already in the database before adding the info (ie so that if John logs in a second time, a whole new row isn't created for him)
Thanks for any help!
That would be a bad idea. What if you wanted to have a seventh link? What if the user format would change?
This solution requires 3 tables:
Users - contains user data (And a user ID).
Links - contains link data (And a link ID).
Clicks - many-to-many relationship between users and links.
That third table would look like this:
user_id | link_id | timestamp
-----------------------------
1 | 2 | ...
2 | 2 | ...
1 | 3 | ...
............
why not just have
increment_ID
Account_ID
Link_URL
Timestamp
Then just insert a new record for each click. You also don't need to manage links since you'll store the entire URL path
I am planning making a PM system for my users, overall it seems easy enough, but the way I have seen tutorials making PM systems, there is one problem.
In the way i planned it to work, there would be rows like, user_from, user_to and then the message - user_from would be the sender, and will see the message in his send messages, user_to will be the receiver and will see the message in his inbox. BUT, what if a user wants to delete a message from their sent folder, but the other user does not want to delete it from their inbox ??
Is there any simple way doing this ?
It could also be nice, to have the messages in conversations, like Gmail and Facebook, but that is maybe to hard to code (any tutorials appreciated)?
Use what's called a soft delete. This means when a record is 'deleted' it is never actually removed from the database but rather a flag is set to delete which allows you to remove it from a user interface while still having access to the data when you need it. So for this situation you could create two more columns called user_to_delete and user_from_delete. When either of these is set to true you would know not to show the message in the respective user's inbox/outbox. Goodluck.
You can fix the issue a few ways, but I would probably add a couple flags (from_deleted, to_deleted) to the table:
Instead of deleting the message, update the appropriate flag to 1.
When listing messages, filter out those that have been flagged.
You can setup the script so that after flagging, if both fields are flagged then you can actually delete the row.
I suggest the following database design:
MESSAGES
+----------+------------------+---------------------------+
| id | subject_id | body |
+----------+------------------+---------------------------+
SUBJECTS
+----------+-------------+--------------+-----------------+
| id | title | author | receivers |
+----------+-------------+--------------+-----------------+
INBOX
+----------+---------------+--------------+---------------+
| id | user_id | msg_id | read |
+----------+---------------+--------------+---------------+
OUTBOX
+----------+---------------+------------------------------+
| id | user_id | subject_id |
+----------+---------------+------------------------------+
When you send messages, you create a new row for all receivers in the inbox table, and in the outbox table one for the sender. In the messages table you insert one row with the ID of the subject and the message body. In the subjects table you insert one row with the title, author and all receivers (if the sender started a new subject or forwarded a full conversation or single message, otherwise add the message in the messages table using the existing subject ID) so that this info is kept even if one of the receivers deletes a messages from his/her inbox (in this case delete the row in the inbox table).
For the outbox there is no need for a 'read' flag, and notice that only the subject ID is used.
Another approach would be add two columns that will determine whether or not the owner or recipient have requested to delete (hide) the message.
owner_id | user_from | user_to | mailbox_folder | Message | Owner_hide | Recipient_hide
1 1 2 Sent Hi 1 0
Yes, there is a simple way of doing it! Having two more columns, respectively sender_deleted and receiver_deleted. If one of them "deletes" the message, then you updated the column with a value of 1. for example. When you display the messages, you select the messages you make sure the value is different than 1. Etc...
You would just create 2 rows, and add a column. example:
owner_id | user_from | user_to | mailbox_folder | Message
1 1 2 Sent Hi
2 1 2 Inbox Hi
Other columns: a unique row id, timestamps, subject line, etc...
Your mailboxes would then be built off of the owner_id column, and each user has their own copy to move/delete as they choose.
To add conversations, you could add a column, or another table. If it's a new message, get a new conversation id, otherwise use the same ID. Query by timestamps.
You could add a user_from_deleted & user_to_deleted rows and display a message only if it is not deleted.
To display the messages in conversations you could add an parent_id and display all the messages with the same parent_id
A PM system is a little more complex that one table. What if you PM more than one person?
In this case you would want multiple tables. One for users, messages, etc... You would link them up using primary and foreign keys.
Try looking up relational databases.
This should get you started:
http://www.databasejournal.com/sqletc/article.php/1469521/Introduction-to-Relational-Databases.htm