I've added a feature to a web site that shows what visitors have visited a user profile. The table representing this holds the id of the user profile and the id of user visiting the profile.
Obviously, it's pointless showing that someone has visited their own profile so I modified the PHP code to detect this. In the meantime, a bit of data was written. This isn't a problem because it represents only a handful of users and I can edit the information by hand.
My question is as follows. In the hypothetical case where I'd have to do the same thing for more data, what would be a good approach to finding rows where id1 = id2 and removing them?
DELETE
FROM table
WHERE id1 = id2;
DELETE FROM `profiletracking` WHERE `visitor_id` = `profile_id`;
If you need to delete it, harakiri's query is good but I have a question, why to add a record in the first place? In time your website could grow bigger and things might get complicated.
I would suggest you to not record it to the database in the first place. You just do more actions and queries while there is a shorter way.
<?php
// Get ID of profile owner;
/* do your query here */
if ($_SESSION['id'] != $profileOwner['user_id']) {
// add it to your database
}
?>
I believe such approach is more elegant and useful, considering in the future your web site might grow bigger and you might need to check your codes again.
Please don't forget such things might be headache. This is a fatal mistake for a programmer. In the beginning, many thinks, ok for now this do the trick, why to bother coding more? In time you will add more and more codes, later you might lose yourself in it. It will be too late once your visitors / customer will start to complain about slow opening pages, eventually bad coding.
Related
I'm making a site where users can make posts and comments, where number of comments made by a single user could get over 1000 comments. On their profile, it would show a list of all comments (by latest, splitting them into pages with 20 comments per page) made by that user.
Considering the database used to store comments would get extremely large, I'm wondering what would be the best way to go about this, since people with more comments would likely be more popular and running a query searching for the user's id through a list of all comments would be the best way to go about it.
Was thinking an alternative could be making a separate column on the user database, which would store all comment ids, and whenever someone were to visit their page, it would go through the comments looking for those ids (limiting to 20 at a time or so).
Unsure which method would be faster, and if the second method is practical. Also if there's any other better method to go about it. First time doing something like this and would appreciate any guidance.
If you are using SQL 2012 new syntax was added to make this really easy. See Implement paging (skip / take) functionality with this query
Skip 20 * page depending on the page you're looking for.
Say I have a table full of comments, each from different users, and I want to count how many comments each user has. Should I have a separate table with the count, and update that on creation/deletion of comments, or should I query the count every time?
I feel like the latter is better, but I want some more experienced input on the matter. Thanks.
Following the good old YAGNI principle, I would suggest you go with the simplest solution for now, which is just counting the number of comments as needed. This is just pragmatic coding.
If, down the line, you find this is causing even small performance problems, then you should replace it with a cached value using a stored procedure or similar, but chances are it will serve you just fine.
So, I realise this probably isn't the clear answer you want, but: if you're making something small, go with the easy solution (counting); if you're making something bigger, go with the easy solution (counting) then upgrade to the harder solution (storing a value) if you find you need it. If you know what you're making is guaranteed to be big (lucky you!) then fine, go straight for the harder solution.
Note: I've said "harder solution" but as you probably know it's only fractionally harder than the easy solution.
After a commnent is created or deleted you should count right in the hour.
If you count every time you will make some desnecessary querys.
Doing a MYSQL count for each user comments would be the easiest way to go about this as below :
$userid= ? ;
SELECT COUNT(*) FROM comments WHERE userid=userid
Updating the table every-time will result to multiple MYSQL calls each time you need to query the comments.
Alternatively you would create a column for comments count in the user , and add the comments for that specific user each time he/she adds a comment , then just querying the user you will have the comments for that user
I wanted to create a notification system like the facebook one and thinking of the structure to realize this system.
I've two tables: notification (id, uid, query, date) and notification_unread (id, nid, uid, date).
I tought to use this the following way:
If I make a comment somewhere, I'll add: my uid, $_SERVER['QUERY_STRING'], NOW() to notification.
With notification_unread I wanted to insert data of posts that hasn't been read yet. In this case nid should refer to the notification id. And only if there may be another new post, data will be inserted in this table. Everytime something has been seen by the user, I'll delete the specific entry from this table.
Well, however I couldn't really figure out, if this approach (including DB Design) of me is somewhere somehow "the wrong" or "too complicated" way
and I couldn't figure out to realize this, because I can't think of a logical way WHEN and HOW to insert data to notification_unread. For instance I don't want to notify myself that I made a new post, after I made it. But I guess I'd still have to insert data to the table?
So, the thing is that I'm trying to insert as much data as needed and realize this most effecient.
I hope you could follow me and would really appreciate any suggestions!
At first glance, it may seem very simple & clean solution but its a downfall afterwards.
As podiluska pointed, its better to have a check field.
You can easily display unread one, but what will happen once a user has check it? You will have to move it in read table which will increase your disk I/O which is the slowest process in any system. You can simply query off last 5 notifications or something.
You may want to create an archive table to move old notifications to archive table. Here important thing will be to maintain that notification table since all the updates will be here. The bigger it becomes, more the performance will suffer. Its a long time effect but you might want to consider the solution now rather than later.
So i noticed in a script i'm using that the id row in the database i have set up is started at 1728.
Is there any specific benefits in starting a database id number at a large number or anything other then 1 ??
It looks somewhat cool for someone.
profile.php?id=1728 looks better than profile.php?id=1
But in your case, it's probably wrong SQL dump which had AUTO_INCREMENT 1728
Not that I'm aware of, although I've seen it used as a very simple security measure, which prevents the first user in a table of users (typically the admin / creator) from having user ID = 1.
No, there are no benefits. As long as the id is unique, it doesn't matter. Some developers prefer to start ids for some rows higher because it seems to look better in a url. For example, this url:
http://www.example.com/user/profile.php?id=142541
looks better than:
http://www.example.com/user/profile.php?id=1
I don't know of any real reason. Perhaps then people don't guess that your admin user ID is 1.
I have seen tables start with non-1 IDs when using auto-incrementing IDs. Every attempted insert will increment even if the insert fails. In your case the table may have incremented to 1728 while the script was being developed so the first "real" record was 1728.
We can only guess. There are no technical benefits as such. But there may be soft benefits. I can imagine that it's done with the intention of having some reserved IDs for old/previous backup .sql dumps or even default database entries.
I occasionally start IDs (if I really have to expose database-internal numbering in the UI) at larger numbers like 1000, so I get e.g. 4-digit numbers for all IDs. Not technical necessary, but may look more consistent.
#Jake Chapman, The reason behind it is that if one see
profile.php?id=1 or profile.php?id=2 ...
all these takes programmer's attention, and tricky programmer would like to play some hacking tricks because they know well what can be done to it.
Numbers likes
profile.php?id=1343 or profile.php?id=2543 ...
Some confusing and don't take attntion suddenly that is why.
I recently started a new community. The forum software is phpBB3, and so far so good. In an attempt to make my community more unique and interesting, I had to idea of having user achievements. Let me give you a quick run-down.
Each user has achievements that they can earn (these will probably be across all users), for example an achievement for when a user hits 1,000 posts, when they upload an avatar, when one of their topics gets 1,000 views and so on. Each achievement has points, for example an achievement like uploading an avatar will be 10 points and reaching 10,000 points will grant 50 achievement points. If anyone here plays World of Warcraft you may be seeing where I'm getting the ideas from. :)
What I'm struggling to get my head around though is how exactly to code this... I could keep a record of all users activity and add it to a special database table possibly, and then check via cron every minute or so if any user has met achievement criteria... but then I also want it controllable through the ACP so I can easily add new achievements and change their points etc. My mind is pretty blank when it comes to anything but the most simple things.
What I really posted here for was feedback on the idea and how you all think I should go about doing this. The coding part should be pretty simple for me once I get my head around how phpBBB MODs need to be written.
Thanks for reading, and I look forward to your replies. :)
Have you checked out this mod?
http://www.phpbb.com/community/viewtopic.php?f=70&t=1696785
It's in beta at the moment but it looks like it's sorta what you're trying to accomplish. Even if it isn't, you can always take it and make something else out of it. I have heavily modified existing mods to suite my site. It takes a little while to get your head around how things are done with phpbb3 but it is easy when you start doing it.
In regards to creating your own, I don't think this has to be done on crontab. You could simply inject a function into the relevant parts of code.
With post counts, there is already a function that updates the description under the avatar of users based on certain post numbers, you could probably put an extra function update_achievement() there. Same goes with the avatar being updated. Unfortunately, taking this approach you will not be able to edit the achievements completely from the ACP but you could possibly have an interface that could enable/disable certain achievements.
You will obviously need an extra table or two for this. Without thinking too much, I would have 1 table that has 2 columns, user and acheivement_id. Then another table which just lists the acheivements ids and descriptions etc..