I want to make a count views system ,I have one for the site count views , but that's in general for the main site , dunno how to do it individually but it seems like this one will not be easy !
So I will show you my old system and in what way does the new should work, so I got this Running so far
$guest_ip = $_SERVER['REMOTE_ADDR'];
$visits = mysql_query("INSERT INTO visitors(ip) VALUES('".$guest_ip."')");
$visitoronsite = mysql_query("SELECT * FROM visitors");
$onlinevisits = mysql_num_rows($visitoronsite);
?>
Visitors: <?PHP echo $onlinevisits; ?>
Of Course It is great to keep track of who and how many , but As my site is with videos and each video has link with php ID which is something like site/index.php?id=8 and that page , What I want to do is to put a counter on that page saying that many people watched using this link and I already have a teory but Has Few Issues
So I created a table called pageviews with 2 columns one ip and the other one page , now here's my question , I cannot use unique because I want to show that that IP has also watched this link but it wount insert it because it will be unique so what do I do to keep one ip unique as for that page only?
On your pageviews table, you should create a unique index based on two columns (ip and video or link id).
You add a unique on your table like this:
ALTER TABLE `pageviews` ADD UNIQUE INDEX `ip_video_unique` (`ip`, `video_id`);
Than you would be able to store unique video views per IP.
On the page, you can get the count of how many IPs have viewed that video by doing a query such as:
SELECT * FROM `pageviews` WHERE video_id = x
where x in this query is the id of the video. In case of site/index.php?id=8 it would be 8.
Its also better if you separate the IPs on a separate table where you store visitors with a unique id and their respective IP and on pageviews table you reference the unique visitor id instead of the IP. Later on, this would allow you to count video views on a table and something else's views on another table but have the visitors(and their IPs) aggregated on a single table.
Related
So I have two different tables, a users table and an articles table. The idea is to allow a user to rate an article, but only allow them to rate it once (possible change their existing rating too but I can come to that conclusion later).
As of now I just have the update value working to allow them to rate the article, but of course a user can rate an article as many times as they want.
To give you an idea of how I have everything working, when a user logins in, a session is created with their user information. So when they go to rate an article, I have the ability to check the user, I just don't know how to stop them from rating if they have already rated a specific article.
The user table consists of among other things their username and their unique ID
and the article table consists among other things the article contents, the article unique ID, and the articles rating.
I had some really sloppy ideas like when the user rates an article their ID gets stored into the articles row in some kind of "users who have rated" column, and then I can do a for loop or something to siphon out all the user IDs and then check if their ID exists in that articles entry but then each article would have a row with possibly hundreds or thousands of userIDs on it and there seems like there would be a more elegant way.
Any help or direction is appreciated :)
Create a UserRatings table which has foreign keys to the users table and the articles table, and stores a row linking the user to the article, and the rating they gave it and when it occurred.
Then if a user tried to rate it again you just check this table for the user ID/article ID combination before allowing it.
And then if you wanted got can do things like show the user a list of articles they have previously rated, etc
I'm trying to make a simple Unique IP counter for gallery page views.
The idea I have is to keep the views records separate from the image records in 2 tables.
Database Tables
gallery
Holds Image: id, name, category, views columns
unique_ips
Holds a visitor ip for the Image name viewed
This example screenshot shows 3 visitors each viewing 3 images. I used free proxy ips.
View Counter
If New IP detected:
Add name+ip to unique_ips.
Increment gallery → name → views +1.
$name = "Image 1";
$ip = getenv('REMOTE_ADDR');
// Increment Views if New IP visitor
// Proceed if name + ip record does not exist in table
if (!DB::table('unique_ips')->where('name', '=', $name)->where('ip', '=', $ip)->exists()) {
// Add Name/IP Record
DB::table('unique_ips')->insert([
['name' => $name, 'ip' => $ip]
]);
// Views +1
DB::table('gallery')
->where('name', $name)
->increment('views', 1);
}
Problem
This view counter works, but all unique ip records are grouped together under 2 columns. It would have to search through all records to find a match, which might slow down with thousands of ip's.
Other Ideas
Use only the gallery table and add a
unique_ips column, which would hold an array of ip's. But how many
could it hold if string/text is limited to a number of characters?
Each name could have it's own Column containing ip's. But then I'd have thousands of Columns.
I could store ip's in name text files instead of in the database.
Is there a better way to design this?
At first it would be faster to use gallery_id instead of name with relationship.
And if you don't want to slow down process on clients side, you can make queued event-listener, that will handle checking and adding record to database.
Check out following link about Queued event listeners
I have a website coded in html/css and a bit of js and jQuery.
MySql is my choice of database.
I have a login-system and users can create their own accounts on my site.
The problem is, that I'm trying to somehow restrict users so that only user A can view content (in this case, images) that I have specified for him. User B can only view its own content and so on.
I tried to mess with Role Based Access Control in php but I failed.
I'm looking for a simple solution. I have one (1) table with users where the "user_id" is the primary key.
Isn't there a way to do something like this?
if(user_id == 1) {
Do somethnig here
}
Charles, as commented there are many "open source content management systems" available that do this out of the box - I personally favour http://www.silverstripe.org/
However your question is about how to structure your database and I would recommend a "many many" relationship ( https://en.wikipedia.org/wiki/Many-to-many_(data_model) ). To create this you will need a table in the middle that stores all the id's from both ends.. e.g.
member - id - plus other fields
member_image - contains only member_id and image_id
image - id - plus other fields
to complete your code example...
$sql = "SELECT 1 FROM member_image WHERE member_id = $iMemberID AND image_id = $iImageID"
...it would be "if" the above SQL returned a row or not they member can access that image
This is more of a general question on how I would approach this.
I have a audio player. No data about songs is stored in the database. I would like to use database for counting likes for each song. My question is how would I organize this?
1.
If I list all my songs in database beforehand and add a column for like, then where would I keep track of user ip address? (not sure if there is a better way than using ip address?) So I prevent of same user voting multiple times.
2.
Every time user likes a song I would store {song title, like count, user ip} (maybe something else) in database. But then I would end up with multiple rows of same song with different user ip addresses, so how would I keep track of likes for every song in this case?
No data about songs is stored in the database
If you want to store data about each song, you should probably add a table for the songs.
not sure if there is a better way than using ip address?
If you have a table with user IDs, use that because the same user can log on from different IPs, and different users can log on from the same IP.
As for database structure, what you proposed is probably the right answer. Once you have a table set up for songs, have a dedicated column just for likes to you can retrieve it easily.
If you want to know which user liked which song (and when) then you need to make a new table like you suggested in your second point. This is called a junction-table, and is used for many:many relationships (m:m). There is no unique id. It joins two tables with many keys (users:songs) and stores any relationship between the two.
Every time user likes a song I would store {song title, like count, user ip} (maybe something else) in database. But then I would end up with multiple rows of same song with different user ip addresses, so how would I keep track of likes for every song in this case?
Even if you end up with many rows of the same song, they are all unique since each has a different user liking it (and vice-versa, you can get all the songs a specific user liked). You wouldn't need to store a like-count in here, since you can just count the number of records in the database. {song title, user id, datestamp} would be fine.
I have one script where am trying to display in a website block The LATEST ARTICLES VISITED BY THE CURRENT USER.
The user can be anonymous or a member.
The articles are in table like [ id_art, intro, text]
So when the visitor X visit a page, i would like to put in the bloc the visited page.
Create a table on the form:
id, tstamp, art_id (key=[id, tstamp, art_id], index=[id, tstamp])
Whenever a user requests an article, add a row with article ID and timestamp. For the ID you can use the user ID for members or an auto-generated ID (persisted in a (session) cookie).
The list is then generated by extracting the latest N records in the table based on the (user/auto) id. (I.e., the actual list is generated by extracting N article titles and links based on a join on the IDs in the two tables.)
Credit goes to silvo for the following point (see comments):
... you should do some periodic upkeep on your table to make sure you don't keep entries that are too old and irrelevant
(Note: This is a generic solution. Nothing specific for Joomla / technology X / ... .)