I'm developing a Web app that revolves around the Twitter API. I'm a newbie and this is my first ever attempt at development so be gentle (please).
The problem I'm facing is:
I have a table that contains the twitter user info: UserID(Unique) Name etc..
And another with specific tweets: TweetID(Unique) Text etc..
I want to be able specify if a particular UserID has Retweeted the tweet(using TweetId) already.
I don't care if he has retweeted outside my App, I just want to know if he did using my web app so I don't display it to him twice.
It's kind of conventional to name your columns in small letters(snake_case_ name_of_column).
Are you asking for schema or query?
If schema,
Firstly, create another (one-to-many relationship) table named user_tweets that have columns (id | tweet_id | user_id). The columns are foreign keys to the tweet table and user_id table
For each tweet, you insert the tweet_id and user_id irrespective if it was a re-tweet or not,
For each tweet or re-tweet, you insert a new tweet record in the user_tweets table and when retrieving record to display a users tweets, you select only distinct records from the user_tweets table where the user id is for the user you are looking for, This returns the distinct tweets.
Hope this helps.
Related
So I have a question, I'm hoping it isn't too subjective.
I have a blog-style website, so on the homepage articles are loaded alongside the date published, the user that posted it, etc. Basic data like this.
I store it in MySQL like so:
article_id username date content etc.
1 user1 2015-05-14 01:35:14 my content a
2 user2 2015-05-16 02:33:15 my content b
This way, I can display it using one query, where I retrieve the username, date, content, etc.
My question is. I want to allow users the option to change their username. There are two options I see for this.
Either I continue storing data as I do now, and manually update tables like this with user-related data to the new username. Or I store data by a user_id rather than username, and have an extra query for each article loaded to get the associated username from another user table.
Which is the correct approach?
I ask this because I assume there's a recommended practice for this situation? Is it normal to store data by username and update it, or to store by id to avoid having to do this - but at the cost of the overhead when querying data. I'm guessing it's possible to display the username for id-based data in just one query, but that would still take significantly longer?
Depends. Do you see there is a 1:1 relationship with Article:User if yes, then storing in a single table will probably suffice but generally an user will publish multiple articles which will make it a 1:* relationship and in which case you should create a separate table for UserDetailsd and have user_id as FOREIGN KEY in Article table probably.
You should create a users table, store user_id which would be incremental and a user_name. When showing the user name in your app, join to the users table and show the name from that table and it will always be current. This is the best practice if you wish to allow user name changes. Updating all usernames it the articles table is not recommended. This will also allow you to store other user related information such as email, join date, etc... without having to keep all that in the articles table.
Create a seperate table with all user-related information and alter your current table, so only content and article related stuff is included. That's what I'd suggest you
Make a separate table for users something like:
-------------------
user_id | user_name
-------------------
Where user_id should be PK.
And another table, lets say article should look like:
-----------------------------------------------
arcticle_id | date | content | etc. | user_id
-----------------------------------------------
Where article_id could be a PK and user_id would be the FK from users table, making a relationship which could be used in other tables as well.
You can create a table for users, and use a foreign key on field username, specifying the behavior on updates. Is something like this:
alter table posts add constraint fk_post_user foreign key (username) references users (name) on update cascade;
In this way, when you update a row on table users, all user names on table posts will be updated too.
I have to maintain the data of friend list of friends who liked a particular category post. And this may be at any level. For eg.
if a friend of A who is B like a wanted post. then I ll maintain the record of A’s friends and B’s friend. Basically my requirement is
If user visit my product site I have to tell him/her that you're following friend already visited the same and they actually recommend you to use this and to build confidence that you are on the right way as your friends are also using it. I also want to suggest A that C who is the friend to B is using this product since this time and C suggest to many for using it.
I know this logic is already implemented in good sites.
I am just a starter. So pls suggest me the database for backend and required things for frontend.
Specially this question is to maintain the record on database. So I am asking for the database what should I use not how should I implement that would be next step.
As I am planning to use Graph database for it. In graph either bigdata or Neo4j.
Your ideas are most welcome and will be appreciated. Thanks
I hope my logic may takes you few steps forward
Initially we have to maintain the mutual friends records
foe example
id mut_id
1 2,3,4
Here 2,3,4 are your friends
next we need to maintain the records who has purchased/visited
prod_id buy_id
1 2,1
Now suppose 3 id wants to buy or visit site then we can show that your friend already visited or buyed product
Friends' relations is a classical many-to-many scheme. You need two tables to implement this:
1. A table with personal data, such as name, email etc. (could be more complex like person-properties relation)
2. A table with friends' retaionships data, usually it contains ID pairs of friends that relation is representing and some data about relation itself, such as category (friend/family/classmate etc) , level of affinity (if >0 it means positive relation, <0 negative such as enemies) and so on. Assume first ID is a person this relation belongs to (and can be maintained by), second ID is a person this relation applies to. Usually such kind of tables is constrained to pair of IDs to be unique, so nobody will be able to add same person as a friend twice
Here is some sample:
CREATE TABLE person
(
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255),
email VARCHAR(255),
PRIMARY KEY (person_id)
);
CREATE TABLE relationship
(
id_person INT NOT NULL REFERENCES person(id),
id_person_related INT NOT NULL REFERENCES person(id),
id_category INT REFERENCES relcategories(id),
affinity INT,
PRIMARY KEY (id_person, id_person_related)
);
Note that affinity and id_category fiels are optional and last one requires table relcategories with INT id field to be create first
Visits of one friend to another can also be stored in relationship in a separate field
I came up with this database design after discussing it with many people over IRC.
In my project, a User aka Member can have many "Teams" & "Projects" on his account and can be part of some "Projects" as well. Moreover, "Teams" can have many "Members" as well including the Member who is creating it.
Now my question is, suppose, a Member wants to create a Project or a Team under his account (later on I want to see all projects created by a specific member), can I do a insert into the using following in PHP?
INSERT INTO projects VALUES(values) WHERE member_id = something
I can get the member_id using the session variable I guess.
Use regular INSERT to create the projects or teams row, then use the ID created there to insert into the projects_members or teams_members. Also settle on plural or singular names for your tables (currently you have team not teams).
Your query would be somethings like this
Insert into
table(columns)
select (columns) from
another_table
where
conditions=.
Just Remember One thing the order and names of columns must match.
If Member wants to create a Project or a Team under his account it will not be possible using current structure.
You need to add one more column created_by on projects and team tables.
The name of "team" table should be "teams".
I want to create a MySQL database for a project in which users can come and make comments on other profile. Every profile has a unique id to identify it, now when a user comes and makes comment on other profile I'll need to store the user id of the person who made the comment and the person on whose profile the comment was made, along with that I'll need to store the comment in the database.
As many users can make comments on a single profile, I'll need to store all the comments and the users who made them on a single profile. For this how many tables should I create and how many columns should they have? For this I'm thinking about creating a table for named user_comments and that has column user_id, commenter_id (all the commenter who commented their id separated by comma), comments (then all the user comments separated by comma).
Will this work?
For this I'm thinking about creating a table for named user_comments
and that has column user_id ,commenter_id(all the commenter who
commented their id seprated by comma) ,comments(then All the user
comments seprated by comma)
God no! You are almost there:
Table comments
id INT AUTO_INCREMENT
recipient_id
sender_id
message TEXT
[ sent DATETIME ]
[ other meta data ]
Store one message in message. Create one row per message. Never store several records in the same field separated by anything.
I'd have a profile_comment table:
id, text, profile_user_id, commenter_user_id, created_at
And a user table:
id, name, email
You can see here that the first table has two foreign keys to the user table - one points to the owner of the profile, and the other points to the owner of the comment. You can sort them in order of created_at to list them as you would on a blog, either in forward or reverse order.
Now, when you are rendering a profile page, you can get the profile id from your query string:
$profileId = isset( $_GET['profile_id'] ) ? $_GET['profile_id'] : null;
From there, you can add it into a SQL query:
SELECT * FROM profile_comment
WHERE profile_user_id = :profile_id
ORDER BY created_at
The colon mark here is a placeholder you can use with a parameterised query, which helps protect against SQL injection. However, you can build the statement as a string if you are careful to untaint any user input you insert into it.
I want to create a Facebook like newsfeed for my users that basically does the following
it keeps track of the activities of users and their friends
users can see recent friend activities on their newsfeed
but i am not quite sure how best to implement this in mysql. Like what sort of tables will I need? What is the structure of these tables? What will I store in these tables? How will I keep track of user and friends activities. I want to build an efficient system that will scale up. I prefer working with PHP and Mysql if possible!
I was thinking of having a NEWSFEED table and when a user does something (posts a comment, etc), I add an entry to that table for the user's friends and the user himself that will show up on their newsfeed.
The table structure would be as follows
uid INT
activity ENUM
activity_id INT
So let's say I have a comments table with the following structure:
title VARCHAR(255)
message TEXT
If the user posts to that table and an entry with ID=5 gets created for that user, then the following entry will be added to the NEWSFEED table
uid=3 activity="comment" activity_id=5
that means that to display the newsfeed for each user, I would have to do the following:
SELECT * FROM newsfeed WHERE UID = ....
FOR EVERY ROW:
CHECK activity type (if activity == 'comment')
**QUERY the corresponding table and display the result (so I would query the comments table an display the person's comment)**
I am thinking of deleting entries more than >3 months old to prevent the table from getting too huge. But I don't like that I am doing independent queries to display for each activity type (just as I did above where I queried the COMMENTS table to display the comment whose ID is mentioned in the NEWSFEED table).