I've seen this a lot on forums, or having a membership somewhere, so my question since a user can be banned by admin which depends on the situation. This situation might be like not returning the item or he did not follow the forum rules, or there is a situation where the forum or a shop does not need his service anymore. So obviously you can be banned forever or it can be temporary, where also this can be changed by admin. Would I have to make a new table ? since the ban can be more than one type and it can be changed my admin, how would I make a table ? not sure how to have an attribute for different types of bans...
You could add a field 'statusId' in the User table, and have all the possible statuses listed in a UserStatus table. No need for user_ID in the Userstatus table.
You could then use simple join queries to retrieve the status of a user, or a list of banned users, etc.
Hope this helps :)
Related
Not sure if this question has been answered elsewhere; I searched but I couldn't find a similar question.
I have a database table (tb_users) with a list of users, ID is primary, EMAIL is unique
I have another database table (tb_memberships) with a list of memberships that refer to tb_users by ID.
I'd like the memberships be added and revoked based on email addresses, not based on their IDs so that a user who HASN'T signed up yet be granted the membership when they sign up. How should I design the table so that a user (that hasn't signed up yet) can be added to the memberships table. Is it a good idea to make the foreign key in tb_memberships the users' email address? Or should these 'pending' memberships have their own table?
Solved this by adding a "ghost_account" boolean to the users table. Using a scope in Rails, I ignored all users who are considered "ghosts" so they can't log in and can sign up normally (ghost_account boolean is set to false once the user signs up). That way, I have a user ID that can be linked to everything else, even if the user hasn't signed up yet.
I have a many-to-many table that stores a record for each allowed role a user can have. If a user updates his roles (add, and removes) roles how should I handle this?
Should I delete all the users roles first and then add the selected ones? Or do some sort of matching?
There are many ways to skin this cat, a few techniques I can think of:
1. Delete all roles and re-insert
This is a straight-forward approach. Remove all the roles for the user and just re-insert. Normally the user only belong to a few roles (less than 10). Also, there is a good chance that no other foreign-keys link to this many-to-many table.
2. Keep track of the changes and apply only the changes
This is more work but more efficient, even if just slightly in this case. Tools like ORMs makes tracking and applying these type of changes a breeze.
3. Apply the changes as the user makes the change
In this case I assume that it is acceptable to apply the DB changes as the end-user associates the user to roles. Perhaps it is a local database and each transaction is short-lived. But I guess this is a unlikely scenario.
I don't think there is anything wrong for this particular case to delete and re-insert.
If a person removes a role why not pass the userID and roleID and remove that one record?
Why would you want to delete all roleID's for a specific userID and then readd them again?
From my comment above, pass two params:
UserID and RoleID
Then you can delete / extract that single tuple.
I'm trying to write up a user management app, but getting confused about how to structure the database properly.
I think the database design would be structured something like this:
Users
user_id
first_name
last_name
email
Accounts
account_id
ldap_access
drupal_access
billing_app_access
facebook_access
Notes
note_id
description
date_added
And I believe the mapping would go like this:
One user can have one set of accounts (1:1)
One set of accounts can have many users (1:m)
One set of accounts can have many notes (1:m)
Many Notes can have Many Sets of Accounts (m:m)
Is this the correct way to structure the database? I'm really confused since I would like the applications fields be a boolean true/false for that particular user. (If they have an account on there or not), and the notes would correspond to EACH of the fields within the Accounts database. (ie: note_id:1 would correspond to user johndoe, application: facebook, note_description = "user no longer has facebook")
Does this make sense?
Any help would be greatly appreciated!
Mayby something like this:
I still don't understand all your needs.
I prefer this design (used in many system like Windows or Oracle)
Table
User
User-Role
Role
Access
Application
Note (still wonder what this for)
Role useful if you have many user with similar characteristic.
I'm a noob, development wise and logistically-wise.
I'm developing a site that lets people take a test...
My client wants the ability for a user with the roll/privledge "admin" (a step below a super-admin) to be allowed to create users and only see/edit the users that they create...
The users created in that "category" or group need some information that their superior provides.
For example, I log in as a "manager", I have the ability to invite people to take the test, and manage those people. Before adding those people, I will have filled out a short survey about myself...
Right now, the users that are invited will be asked some of the same questions as the manager. I'd like to cut down the redundancy by using the information put into the database by the manager and apply it to the invited users.
How do I set up my database to work with this criterion? I'm a little confused about how to do this! Let me know if I can add more details...
(This is a mysql and php app)
I am sure there are several ways to do this but here is one that comes to mind.
In the "users" database, I am sure you have a column to specify which manager is assigned to the user by some kind of user key. Well If this field has a value, then pull the info from that users (manager user) record.
Example:
table 'users'
key----name------managerid-----questionone------questiontwo----
1-------randy-----0------------------california----------c++--------------
2-------bob--------1------------------nevada------------------------------
Since record(key)1 has managerid == 0 then use questiontwo record to answer "Question 2".
Since record(key)2 has managerid == 1 then pull questiontwo from record(key)1 and use that for answer to question two.
You could either insert this information into the record or use it from the manager record dynamically as needed, which thought the space is still being used in the database, would be helpful since manager data might be updated and you might not want to have to update all records with that share the managerid wheh info is changed.
Make sense?
Say you have a ServiceCall database table that records down all the service calls made to you. Each of this record contains a many to one relationship to Customer record, where it stores which customer made the Service Call.
Ok, suppose the Customer has stop doing business with you and you do not need the Customer's record in your database. No longer need the Customer's name to appear in the dropdown list when you create a new ServiceCall record.
What do you do?
Do you allow the user to delete the Customer's record from the database?
Do you set a special column IsDeleted to true for that Customer's record, then make sure all dropdown list will not load all records that has IsDeleted set to true? Although this keeps the old records from breaking at innerjoins, it also prevents user from adding a new record with the same name as the old Customer, won't it?
Do you disallow deletion at all? Just allow to 'disable' it?
Any other strategies you used? I am guessing everyone have their way, I just need to see your opinions.
Of course the above is quite simplified, usually a ServiceCall record will link to many other entity tables. All of which will face the same problem when they are required to be deleted.
I prefer to set an IsDeleted flag, one of the benefits is you can still report on historical information (all teh data is still there).
As to the issue of not being able to insert another customer with the same name, this isn't a problem if you use an ID column (eg CustomerId) which is generally auto populated.
I agree with #Tetraneutron's answer.
Additionally, you can create a VIEW that lists only the active customers, to make it more convenient to populate drop-down lists and such.