Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am making a small side project on which guests can vote on some sort of posts with either agree or disagree, then I want to save the IP that voted in the database. I was thinking of saving an array of IP's that voted in the 'posts' table, however that might be insufficient I guess. Would a separate table like the following be recommended?;
post_votes:
post_id, IP
Doesn't matter if the user voted agree or not, as long as the vote is counted they won't be able to vote again. What's the best approach for this? Thanks in advance.
Yes, the best way is to use a seperate table with identifiers (e.g. post_id) to identify the posts.
Never save more than one information per field - saving the information in an array in the same table is cruel.
However, do NOT store the IP address 'as is' in the database as this is illegal in many countries and can cause a lot of trouble!
Instead use a hashing function like hash_hmac (http://php.net/manual/de/function.hash-hmac.php), hash the IP address and save the hash instead..
Because hashes are one-way functions, this will ensure anonymity for the user but still give you the opportunity to prevent users from voting several times.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've a large users table on my database with 80k users which cause mostly login problems.
I have a solution! Don't know whether it's a good one or not!
I want to create other users tables for new users and save last IP of them in it.
So in most cases of login by knowing Ip range I can redirect users to the right table in login. If it's not the right table then it will check other tables.
So I think it will increase speed!
Is it a good solution!? I will be appreciated if anyone come up with a better solution!
Table Structure
Is it a good solution!?
No, it is not a good solution. It is, in fact, a terrible solution.
From your table definition, we can guess that your users give their email addresses to log in.
Try creating an index on that column.
ALTER TABLE ci_users ADD INDEX index_email (email);
Once you do that, queries of the form
SELECT something FROM ci_users WHERE email = 'user-supplied-value'
and
SELECT something FROM ci_users WHERE email LIKE 'user-supplied-value%'
will start to be very fast, almost as if by magic. That's DBMS technology at work.
You should read about indexing. http://use-the-index-luke.com/ is a good source.
If you will have some users supplying a phone number, and others providing a email address, you need two different indexes, one for each.
A typical table can have as many indexes as you need. With a table that size, you can create them easily without disrupting production. But don't create indexes until you know you need them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
For example i have a field user-id in my mysql table users which identifies a user uniquely. If someone requests for example the friends list of a user i return a json array witch includes the user-id of each friend and additional data like name.
So my question is if it is an good idea to send these user-ids directly to the client. Is this insecure? Are there ways to hide the id?
Regards
It depends if leaking the ID information from your application is a serious issue or not. If you're in a highly competitive business where knowing the number of users on your system is valuable information, or where you're worried someone might step through them sequentially to download your database systematically, scrambling them does help.
Using a cryptographically random identifier or a UUID are two of the more common ways to solve this problem. A truly random identifier offers more security but will take more care to construct as there's many ways to get this wrong.
It's worth noting that sites like Stack Overflow leak user IDs because there's no value in hiding them. For example, your profile link has the user ID in it: 2441032.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
So what I am looking to do is have a survey whose answers are populated into an SQL database. One problem I am not sure how to avoid is allowing duplicates into the database.
For example, I want the user to tell us which organization they are representing.
Say one user enters "big brothers and big sisters" and another, from the same organization enters "Big Brothers & Big Sisters". I have a separate Organization table these answers would be populated into. How would I prevent this from creating two separate rows? There are several instances of fill in the blank questions that I foresee this problem occurring with.
You might try utilizing the Levenshtein algorithm ( https://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Levenshtein_distance ) and some languages (such as PHP) will have methods to utilize this built in. In addition, you'll probably have to build permutations of the input string by using common substitutions (& / and) and try validating the permutations against the database to make sure that it doesn't already exist.
For what it's worth, it might also be a good UI decision to present the user with similar options to make sure that they really did or didn't mean to type in what they did.
Sorry if it's not much help; not sure what your total requirements are. Hope this helps!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I know there are already some of these questions but I'am still not sure what to do.
The issue
I would like to have visitors being able to up or down vote once. First I thought I'd use the IP address to keep track of them, but apparently mobile IP addresses are changing frequently (mine every page refresh).
Other people state that you should track them by user id, but I don't want them forcing to register.
So... is there any way to keep track of unique mobile users. With either sessions, cookies, IP addresses or maybe something else?
For me sessions seem the best way to do it. It allows the users to vote multiple times, but not that fast and if it won't slow down the website to much.
To give you people an example: http://votezine.com/list/penguins-are-awesome-for-many-reasons-what-do-you-like-most
You can use browser fingerprint on top of the methods you've mentioned.
https://panopticlick.eff.org/index.php?action=log&js=yes
http://valve.github.io/fingerprintjs/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've got a question about storing information in a mysql database.
If i have user information, should i have separate tables to store each type of information? Or should I use 1 single table?
Let's say I have user email, username, password, first name, last name, address, gender etc...
Should I have 1 table to store email, username, and password, but another table for firstname, lastname, address and gender? Perhaps a separation from user info and account info? What do you think?
I'm not sure from a query/performance standpoint if there would be any difference by splitting up. Also, a JOIN query using the assoc. index should be able to link both tables up by User ID or some other auto increment value. Not sure what to do here!
Thanks!
Unless you have a very good reason, use proper database normalization techniques and have one table per entity type.
You're talking about a user here, so unless user and person are fundamentally different you should store that in one table.
If one user can have multiple logins, which is hopefully not the case as it tends to confuse people, then you may want to separate that out one-to-many. Otherwise, use the simplest thing that could possibly work.
As always, follow the advice in a guide book like PHP The Right Way paying particular attention to the part about password security.
Using a
development framework like Laravel is an even better plan as that has a security model built-in that you can use.
Depends on the functionality of your application / functionality.
But, you should normalise your datamodel.
Have a look at Codd, http://en.wikipedia.org/wiki/Database_normalization
How many records do we talk about? Even with a few thousand, its not something to worry for. Once you get into 100K + then joins (and indexes) are getting important. And then you want to make sure your datamodel is normalised.