I've a problem deciding where to place a certain table field within my database.
The database is for a classified ads website.
I want registered and non-registered users to be able to post ads. If an unregistered user posts an ad, the site should ask him for the contact phone, if the user is already registered, then the contact phone stored in the users' table should be used.
Now my question is, would it be possible to store the contact phone for both registered and unregistered users in the same table field?
If so, where should that field be put, in the Classified ads table, or in the users' table (noting that each user within the table has a unique Id, thus, filling the users' table with unregistered users just to get their contact phone will just fill the table with useless data)
Thanks in advance !
well you can put the phone field in the ads table, with a is_registered field inside. Then via php you check is_registered and then you know where to search for phone number.
Regards
You can store unregistered users' phone numbers in the same column of the same table, and you probably should. It makes the transition from unregistered user to registered user dead simple--you don't have to move or re-enter phone numbers. And if any user changes phone numbers, it only has to be updated in one place. (Do you know how many people accidentally drop their cell phones in a toilet every day? It's staggering.)
If you're now relying on the presence of a phone number to identify registered users, you'll need to fix that first. (I don't think you're doing that, but if you are, fix that first.)
You said
filling the users' table with
unregistered users just to get their
contact phone will just fill the table
with useless data
If it's useless, don't store it. If you need to store it, it's not useless.
You can always delete unregistered users when their classified ad terminates. But . . .
Does it make sense to require a contact phone number instead letting the user choose to leave either a phone number or an email address? Personally, I prefer to use a throw-away email address for things like this.
I would look for flexibility in your design, but if your logic treats users mostly independently of whether they are registered or not, I would use the same table and just complete the rest of the user's data for the registered ones. I wouldn't store user data on the ads table, even if only for clarity of data organization.
I guess your registered users will all have a username and password, so you can just check the presence of these to know if they are registered or not. If you don't want to change your logic in the future you should choose this distinction carefully of course.
A different approach: Why not making registration so easy that it makes no sense to have unregistered users? I you are already asking for a phone number in all cases, just add a password field or generate one automatically and you have all your users registered.
I would ask for an email so you can send the password and perhaps ask for account verification (now or in the future).
Related
I am using PHP , MySQL for Handling My site. I have a user table called user_table containing user_id PRIMARY and Now user can chat with other user. For that I am using a table called message_table. this table contains essential fields like msg_id , sender_id , reciver_id , replay_id etc. this works very fine.But I need to handle also guest users[Not registered] with this chat. how can I handle them. I inserted the guset_id as the mixture of entering time and his name to a table called guest_table. Now I can use this guest_table like user_table. Is that a good idea ?
But I need to handle also guest users[Not registered] with this chat.
These guests look to me like a special sort of user. I suggest you handle them as if they were users. You may wish to put a column called something like is_guest in your user table, and set it to 1 when you know the user is a guest.
Keeping a separate table, parallel to the user table, for your guests is NOT a good idea. It will greatly complicate your queries, especially when a person in your user table communicates with a person in your guest table.
Instead, put everybody in the user table, guests and registered users alike.
A nice little benefit: if you convert a guest to a registered user, all you have to do is flip the is_guest flag and let them specify their own username and other data. They get to keep their history.
I am writing DB schema for my application. App's users have unique phone number.
Every user can have multiple contacts. I have made user_contact table to have mapping between user and contacts.
contact is itself a user.
Now I came to know that every contact can have multiple phone numbers. Now I am thinking how this will be managed in DB.
Do I need a new table?
P.S. we are using mysql database with java 8.
There can be different ways.
If you assume there will be limited phone numbers for each contact, you can add multiple fields one for each phone number, e.g. PhoneNo1, PhoneNo2, PhoneNo3.
If you want to keep it flexible, you can add a table contact_phoneNos with foreign key of Contact, and keep a record for one phone number.
I suggest the first solution as its commonly implemented, like Home No. Office No, etc in each field
I have 4 tables,one is credentials(it holds an id, email and password), the other 2 are for business users and regular users of the app.
The business users table holds crID(foreign key)name,lastname,address etc...
The regular users table holds crID(foreign key),name,lastname etc...
The 4th is the booking table, it holds a bookingID, bookedfrom,bookedfor(the last 2 being foreign keys that point to the credentials table).
If a regular user registers in the site he closes a bookingslot and that is stored in the booking table, his name,last name are stored in the regular users table and his credentials in the credentials table.
The business user table just holds the business user for which a booking is made by the regular users.
Here is a graph:
db image
The question is what to do if a regular user does not choose the web to make the booking but makes a call. The business users are given the option to make the booking "manually" also. I am just having difficulty how to integrate that in the db.
As I see it I need to make the following:
Create a booking slot in the bookings table
Create a new regular user entry in the regular users table and at the same time create another column that would indicate if the user is registered or not.
create an entry in the credentials table but without password/email since this he will not be a registered user...he just made a booking using the phone.
WHat is your opinion.If you want I will post some show create statements. I think I made my point.
I would personally merge business users, normal users and optionally credentials in one single userstable.
Since I don't see the need of two seperate tables for your users, it would simplify drastically your data model. You just need a flag to determine if the user is a business user or a normal user.
For the rest, I think that having a null password is enough to determine if the user hasn't registered yet.
In my every application i want to create a unique url for users profile as http://app.com/username .
I have the name of user is : 'Vijay Kumbhar' i can create http://app.com/vijay_kumbhar, but if there is another user registers with the same name then what will be better way of creating url for that user.
one way is to add vijay_kumbhar_1, but i dont think this is the proper way of creating a unique url
Can you please suggest me the better way of doing this.
Keeping in the User experience in consideration, firstly provide the user with unique id, through which you can identify the User easily. After that you can allow the User to opt for any new User Name (screen name), but there should be a check again that the user name has to be unique again. Depends upon your requirement. Do keep us posted what way you opted at last.
You can use the same approach as stackoverflow using
stackoverflow.com/users/unique-number/user-name
Usually user names must be unique. If you're using login in the URL, then they urls will be unique. It is common thing to prevent registering two users with the same login.
EDIT:
If you'd like to keep usernames not showing (e.g. for some security reasons), you can use in URL hashes from users logins, not the logins e.g.
app.com/mylogin > app.com/123123123
You keep your registered users most likely in some kind of a database. In SQL it is natural that every row has a unique ID. You could use such an ID as a part of the url, instead of an own running number for every name combination.
You definitely need to make sure you do NOT show the actual "username" in the URL if you have a publicly accessible URL.
If you use an ID number, just remember to avoid the error that Wordpress made - creating the user IDs sequentially, starting with the default admin user as "1".
That made it easy for hackers to query with something like
example.com/profile?author=1
That would return
example.com/admimuser
And show him the actual username of the admin... and then cracker starts pounding away trying to brute force the admin username's password.
And never show the login name to anyone or in any URL other than to the user or admins!
I was wondering if it would be better to have things like perishable_token (used for account validation and resetting of passwords), banned (boolean to check if the user is banned), email_verified (boolean to check if user's email has been verified) in a separate table in the database, as it will rarely ever be used.
Also, I have my applications set so that a user logs in with a password and email address. The email address will only ever be displayed on the User Edit page, and the password will never be displayed anywhere. As these two things will pretty much only be used when the user logs into their account, is it necessary to have them in the main User table in the database? Or would it be better (faster?) to have them in another table?
The user table will have -many- other things that will be displayed on all pages and will need to be checked often (things such as a user's "money" "credits/points" "logged_in?" "badges" etc).
Since your user table has many other things, it seems unlikely that you would get any performance improvement by moving those five columns (which seem not to contain much data) into a separate table.