So I am having a discussion with a friend of mine whats the best way to verify an account. We have come up with two methods:

Method 1


The first method there are three steps:

  • register user and automatically create an row inside verification table
  • send email to user with verification code
  • after entering correct code delete row from verification table

So it would look like this:

public void registerUser(User u){

Checking would be like this:

public void checkCode(String code){
  boolean isCorrect = checkVerificationCodeWithHashedValue(code);

Do only disantvantage of this method is that I always have to query the verification table in order to check if the user is verified. But it shouldnt be a big performance problem because i always delete the row

Method 2


In the second method there is an extra field called isVerified. So basically instead of deleting the row I just change the field isVerified to true which makes it easier to filter. The problem with that is that its against relational design rules because when I change the verification table(insert/update) i also have to change the usertable (set isVerified to false)

New contributor
igodie is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

put on hold as off-topic by Toby Speight, πάντα ῥεῖ, Peilonrayz, yuri, 200_success Jun 12 at 20:27

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Toby Speight, πάντα ῥεῖ, yuri, 200_success
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Don't worry about the relational design rules. Triggers and constraints can help you out here. \$\endgroup\$ – dfhwze Jun 12 at 19:51
  • 3
    \$\begingroup\$ Hey, I think you would get a better answer on stackoverflow or a more specific site like dba.stackexchange.com. This site isn't really intended to review a potential implementation, the question is a little off topic here. As an aside, I don't think you should ever store a users password, full stop. Generate the (cryptograph) hash of the salted password client side and only ever send that. Sending the user password anywhere opens you up to any vunerability (or plaintext logging!) that the password goes through, including the network stack, your server, and your db stack. \$\endgroup\$ – spyr03 Jun 12 at 19:51
  • \$\begingroup\$ @dfhwze so u suggest an extra attribute? \$\endgroup\$ – igodie Jun 12 at 20:06