Is it true to have a null info?

Question

0.00/5 (No votes)

See more:

SQL-Server-2008R2

hello,
i want to design a shopping system,
my system has some user -> ( admin(*) - admin(level2) - seller - buyer(registered) - buyer(not registered) ).
i have two table for register :

1- User (UserID(pk) - role - username - password)

2- UserInfo (UserInfoID(pk) - tel - name - fname - address - city - UserID(fk))

i want to set username and password nullable because i want to register some buyers info without any username and password (buyer who not registered).
i dont give permission to other user for insert null username and password.
i check if they inserted username and password therefor they can register.
but username and password fields are nullable.
is it true to have some rows without any username and password but for some rows have them?

What I have tried:

all of the fields are mandatory except username and password fiels but users who wants to register should insert them(i check if they didnt insert these field cant register).
null able is just for not register users.

Posted 29-Jul-16 4:01am

saeed rajabi

Updated 29-Jul-16 4:41am

Add a Solution

Comments

Tomas Takac 29-Jul-16 10:17am

I missed your question. You can set the fields to nullable and not populate username and password for not registered users. What's the problem? You can also have a bool flag saying if the user is registered or not and build a constraint on top of that to be safe.

saeed rajabi 29-Jul-16 10:25am

my question is : some username and password has no data is it true?

Tomas Takac 29-Jul-16 10:33am

I don't understand your question. If you are asking if there are such records in your database then I cannot answer that. If you are asking if it's possible to do this then the answer is yes. If you are asking if this is a good idea to implement it in this way then I'd say you need to provide more context.

Richard Deeming 29-Jul-16 10:32am

It looks like you're storing passwords in plain text. That's an extremely bad idea. You should only ever store a salted hash of the user's password.

Secure Password Authentication Explained Simply[^]
Salted Password Hashing - Doing it Right[^]

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Accepted Answer · 2016-07-29T04:41:00

You can have nullable username and password (since your PK is the ID column) because each row is independant of each other and null is a permitted value.

I wouldn't do it myself, as there isn't any "real" need - instead I'd probably add an "anonymous user" to your roles list and use the role instead - that way you can also make it easier for the system to restrict what they can look at and divert them to the registration page if necessary. Rather than a null username and password, I'd use "New customer" and a blank password and let the role deal with what they need to do.
(It also reduces the work you have to do as you can just display the username on every page by the shopping basket without having to add an extra check for null values)