Hello my question is if it is better to have a temporary_users table in my mySQL DB for those users who did not verify by email their account yet. If a user is verified then his data is copied into the users table.
Otherwise, all users, verified or not, will be saved in users table where there will be a new column with a random number. When the user is verified, that value will erased meaning that he is ok to login.
In the future I will create a forgot password function with the same structure as you suggest me.
What is the best method to have ?
Store all users in a single table, and store validation/not-validated state with each record. Whether you add a is_validated column, or simply store a unique token and set it to null for validated users is up to you.
Duplicating an entire table for the sake of adding a single column of data is not a very good practice, and it will be unwieldy; You want to be able to find the user based on their login credentials, and tell them their account is not yet activated. To do this with two tables will require two queries.
It's best to use a column in your main table as a flag for "verified" and "not verified".
When the user registers, insert their info into the database and set the "verified" colunmn to something representational of "not-verified" like a 0.
Once they verify, update your verified column for that user account to something representational of "verified" like a 1.
It is a waste of resources and extra database queries to create a brand new table for temporary users when it is more efficient to simply have a column that represents the users status, like "verified".
You can take this even further and instead have a "status" column for each user. Create a key of values that represent the users state of being, for example:
0 - Created, not verified
1 - Verified
2 - Inactive / Disabled account
3 - Banned
etc..
This can all be controlled by using one column to control the state of the user. It is absolutely un-necessary to have a seperate table for one state of being when you can use one column on the record itself to control as many states of being as you want.
Related
After entering data in html form while clicking on button to add the data in the database, I want to check whether the user already exists in the database. I am using php v5.3.5 and mysql v5.5.8.
Data is stored in 2 tables simultaneously named person and other and there is no primary key(in both columns) since there is no column which can be treated as primary key
Can any one help me how to do that??
Code is::
$sqlComm="Insert into person(Name,father_name,date_birth,
gender,Res_Address,Mobile_no)
values('$name','$fatherName','$dob',
'$gender1','$resAddress','$mobileNo')";
$sql="insert into other_staff(p_id,employer,off_ph_no)
values('$pId','$employer1','$phOffice')";
Id is automatically generated for each person which is retrieved and stored in other table as p_id.
combination of name,father_name,date_birth,employer can be made unique..
It seems like none of the fields suggested can be a primary key, any of them or a combination of them cannot uniquely identify a person. It's a really strange database design and I urge you to check your database design.
You will have to a search by doing a separate select query to find if the user exists. Also Ensure both the statements are executed inside a transaction.
You will have to think about what makes a person unique for your schema/application. Changing the mobile number probably does not make one a new person, but am i the same as an existing person, if we share the name, father_name, date_birth and gender? If so, make that a unique key and you will have something your database can tell you, that it already exists. Just in case you did not already know: keys can span multiple columns.
Dispite with a bad schema, we can find a way(given below) to check weather a user exist or not. BUT I think you also want to check second table THAT with particular user there is an employer or not. Then here is problem in your database cause there is no column in PERSON or OTHER_STAFF's table which can tell us the Particular employer of a specific user in PERSON table
Solution: But for this condition you can use cross join to get nearly correct result:
if($result=mysql_query("SELECT 1 FROM person p CROSS JOIN other_staff e WHERE p.name='$name' AND p.father_name='$father_name' AND p.date_birth='$dob' AND p.gender='$gender1' AND p.Res_Address='$resAddress' AND p.Mobile_no='$mobileNo' AND e.employer='$employer1' AND e.off_ph_no='$phOff';")){
if(mysql_fetch_array($result)){
//exist
}else{
//not exist
}
}
Suggestion: Next time store auto generated id in PERSON and OTHER STAFF table BUT for this project- If you can store p_id in PERSON table then this query will return 1 on exist, otherwise null(same in above):
$sql="SELECT 1 FROM person p LEFT JOIN other_staff e ON p.p_id=e.p_id WHERE p.name='$name' AND p.father_name='$father_name' AND p.date_birth='$dob' AND p.gender='$gender1' AND p.Res_Address='$resAddress' AND p.Mobile_no='$mobileNo' AND e.employer='$employer1' AND e.off_ph_no='$phOff';";
I am not sure if what I am trying to do is even possible but, if it is, I am obviously not Googling properly and would appreciate any assistance I can get here, even if it is just a link to an "Idiot Guide".
Okay, at the moment, I have a database table of 150-odd records. Each record contains basic details (name, location, contact information, etc.) and login credentials (UserID, password, et al). These details are captured by the website admins (i.e. no general public registration) after the prospective user has undergone a successful interview process. When a record is created, a 6-char "username prefix" is assigned to the user (e.g. 'UNPREF') and this, along with the auto-incremental UserID (e.g. 125), is used as the username (e.g. UNPREF125) to log into the website. However, the username is not actually stored in the the database. Instead, when a user logs in, the login script splits the provided username and the two chunks are checked against their relevant fields.
In addition to this primary user table, there are a number of other tables which contain additional information (for instance, educational qualifications, work history, etc), which are linked to the user by means of the UserID, as per the primary table. Now, both users and admins can update a user's data and, therefore, I have created a field for each row that logs who last modified the record (modby) and when (modon) so that, if there are any shenanigans, I can ascertain who fiddled last and, in theory, deal with that particular individual without any "he said/she said" nonsense.
Now here is the tricky bit. My users and admins are stored in separate databases on separate servers (the latter being beyond my control) but I have recently discovered the joys of Federated Tables, which work brilliantly. One small quirk, tho; because my users and admins are stored in separate databases and because I want to maximise the number of records I can store in a single database (there is a size limit of 100mb per database), with the company's current rate of expansion and each branch requiring two admin accounts, it is not an improbable scenario that a user and an admin will end up with the same UserID. Therefore, the modby fields store the full username (i.e. UNPREF125 - admins get their own, unique Username Prefix so as to differentiate between admins and users)
Now, perhaps it is because I am such a newbie at Federated Tables but I can't seem to find a way to compare a field in a table on Server A (i.e. modby) with 2 separate fields (i.e. unprefix and userid) in the Federated Table, called from Server B, but I have come up with a workaround by creating an additional field in Server B's table, namely username, which stores the merged values (namely 'DBPREF125') and modby is checked against this instead, which works fine (I'm sure there is an easier way but I will save that lesson for another time).
Now, here is my question. The admin table is currently small (only 26 records) and so I captured the usernames manually, using phpMyAdmin, but I would prefer to avoid having to manually create usernames for the 150+ records in my users table. Is there any way I can get MySQL to pull the values of the userid and unprefix fields, join them together and store the result into the username field of the same record or would I need to turn to PHP for this and, if so, how would I go about this?
I apologise for the length of my question but I hope this will help explain why Google was not my friend today.
Many thanks in advance.
To store the combination in the table:
UPDATE TableB
SET username = CONCAT(unprefix, userid);
Or you can just use it when comparing:
SELECT *
FROM TableA a
JOIN TableB b
ON a.modby = CONCAT(b.unprefix, b.userid);
I am building a service which provides a newsletter system for the users.
My question is, how to organize it on the database? user opens account -> there is a news row on the data base -> how the email will be stored? I thought about something like:
user#mail.com,HASHCODE|user2#anothermail.com,HASHCODE|someone#mail.com,HASHCODE ..
(that will be stored on one field of the user's row, HASHCODE for remove the email)
Then using explode() to order it in an array. but I don't know if it's the best way to order the mails.. what do you think?
Why don't you store emails in separate table UserEmails and make a relationship with user table. For starting point you may look at this link
Useremail table will have three fields UseremailID email UserID
UseremailID email UserID
1 sss#ss.com 1
2 asasf#ssf.com 1
I would recommend you to read some relational database so that you get some idea about tables and relationships
You should consider using a table structure like this:
Table 'subscription'
id int(20) PK auto_increment
email varchar(100) UNIQUE index
This will cause you having to insert a new row into the table with a ID and a e-mailaddress (which will both be unique so you dont get double records)
I would create a table to store the newsletters and another one to create the relation between users and newsletters so you'll have a better control over your information.
Three tables: User, User_Newsletter, Newsletter
The User_Newsletter will only store the user_id and newsletter_id
Database services don't seem to be so flexible (even though they were introduced to be). Normal UNIX filesystem hierarchy and plaintext files are the best way to store information. You don't know the internal structure of a database. But you know everything about your filesystem, including the file permissions and encryption
For example, take Croud Mail, a free e-mail newsletter service from me. I don't use databases, but it the coding is very flexible and safe.
I'm used to building websites with user accounts, so I can simply auto-increment the user id, then let them log in while I identify that user by user id internally. What I need to do in this case is a bit different. I need to anonymously collect a few rows of data from people, and tie those rows together so I can easily discern which data rows belong to which user.
The difficulty I'm having is in generating the id to tie the data rows together. My first thought was to poll the database for the highest user ID in existence, and write to the database with user ID +1. This will fail, however, if two submissions poll the database before either of them writes to it - they will each share the same user ID.
Another thought I had was to create a separate user ID table that would be set to auto-increment, and simply generate a new row, then poll that table for the id of the last row created. That also fails for the same reason as above - if two submissions create a row before either of them polls for the latest user ID, then they'll end up sharing an ID.
Any ideas? I get the impression I'm missing something obvious.
I think I'm understanding you right; I was having a similar issue. There's a super handy php function, though. After you query the database to insert a new row and auto-incrementing their user ID, do:
$user_id = mysql_insert_id();
That just returns the auto-increment value from the previous query on the current mysql connection. You can read more about it here if you need to.
You can then use this to populate the second table's data, being sure nobody will get a duplicate ID from the first one.
You need to insert the user, get the auto-generated id, and then use that id as a foreign key in the couple of rows you need to associate with the parent record. The hat rack must exist before you can hang hats on it.
This is a common issue, and to solve it, you would use a transaction. This gives you the atomic idea being being able to do more than one thing, but have it tied to either a success or fail as a package. It's an advanced db feature, and does require awareness of some more advanced programming in order to implement it in as fault-tolerant a manner as possible.
I'm trying to create a MySQL database that will hold all of my users and logins.
The table columns are:
User_id
passkey
points
The user_id of each user has to be unique, and same with their passkey. Points is just an integer value that I will edit from time to time. Now, when I get a user to my site, I have to check if he is a new user or an old one. I check by seeing if their user_id is in the database already, and if not, I create a new entry to the table that inputs their user_id, passkey, and 0 for points. So, when I create the table, do I still have to specify unique for the user_id and passkey, even though I'll be checking first before creating new entries?
And how would I check if the user_id is already in the system? I'm thinking something like:
SELECT * FROM customers
WHERE user_id='test'
And then count the rows, and if it is zero, I create a new entry, right? I'm trying to make sure I get everything right before I run my code. Thanks.
It's a good idea to anyway mark the fields as UNIQUE, because in the case you miss something in your code, the DB will still catch the error before things break down. I'm not sure why you want the passkey to be unique though, is there anything wrong with two users having the same passkey?
Your query is fine, but I guess you don't really need the actual user details when checking, so you can just ask for the count:
SELECT COUNT(*) FROM customers WHERE user_id='test'
and if the returned value is > 0, the user_id already exists.
You should specify unique and auto increment so that you just fill in NULL and it does it for you.
However, I would worry that you should have usernames and passkeys...
First set the passkey field default to 0. Then for the user_id make it auto_increment. This will go up by one each time a new row is added (e.g. new user). You will not need to check if the user_id is in the system when you insert to the database.
When inserting you just need to specify the passkey, presumably this is the user's password. All of the field editing can be done in phpMyAdmin, under Structure for your tabel.