I'm currently making website for selling stuff and my system requires some specific user rank's to have workers under them. So i was thinking if it could be possible to make some database design like this ( See picture below) and add user_id with worker_id (foreign keys pointing to user_id key) and then retrieve through a query how many workers a user has.
Adding a picture to understand my idea.
Thanks.
Related
I apologize if someone else can readily find this question - I tried phrasing it a few different ways and didn't see an answer on SO.
I'm trying to create a mocked up social network - very simple, basically conceptual at this point. If a user creates an event to invite other users to, how do I attach the responded users to the database in the most meaningful way? In other words, what is the best way to do this such that the attached users are all query-able? I'm not, for instance, going to create a field called "users" and just keep appending user ID's to it.
So far, my table design looks something like this:
eventID (PK)
eventDate
eventTime
eventLocation
Now I'm stuck trying to figure out how to attach users and add a flag indicating which user(s) might be hosting.
I would love some feedback on design! Thanks in advance.
Since more than one user can respond to an event invitation, you will need a separate table for "eventResponses". It could have a schema like:
eventID (FK)
userID (FK)
response (varchar(10)) -- Yes, No, Maybe, whatever
A uers's yes / no / maybe response to an event would be stored in this table. You can then look at how many responses a particular event has received.
Im building a webpage where users will be able to create accounts, and every account will have its own subdomain. So there could be URL-s like this:
www.user1.domain.com
www.user2.domain.com
...
They will have their own pages too, like this:
www.user1.domain.com/url-1/
www.user1.domain.com/url-2/
www.user2.domain.com/url-3/
...
So I need to store account_url and page_url in database.
I did it like this, I have users, accounts and pages tables.
This is how my tables look like:
USERS:
user_id PK
user_name
user_pass
...
ACCOUNTS:
account_id PK
user_id FK
account_url
account_name
account_type
...
PAGES:
page_id PK
user_id FK
page_url
page_name
page_content
...
Now the problem is this, since I get url like this:
www.user1.domain.com/page-url/
The only information I can fetch from url is account_url and page_url since its in URL, dispatcher/router gets these two variables. account_url is subdomain, and page_url is segment after domain.
Since there will be multiple users I always need to get that user_id so I can update/delete rows that belong to them. So I need to update page_content where user_id belongs to this user and page_url is the one from URL.
But I dont have user_id. And when I would like to update page_url_content, first I need to find user_id, like this:
SELECT user_id FROM accounts WHERE account_url = something
And then when I have user_id I can update content of a page or do any other action.
So is this a good design?
Its normalized and clean, but when Im using this in every action inside controller I need to fetch user_id first joust to be able to do a real query I wanted.
Now, I could use account_url for Primary Key, and have all tables relate to that primary key. So when I get URL I already know the Primary key since its in the URL.
Is this a good case to use Primary Key in URL, or Im doing something wrong?
I prefer to always have my primary ID keys as integers for joins. That said, there are a bunch of ways to help make your site snappy.
You could index the account_url column so look ups are more efficient.
Or you could cookie the users ID and use that value instead of querying the database each time. Granted, you would want to do some session tracking so someone can't spoof someone else.
One presumes the user will be in control of the name of the subdomain, so embedding the user ID into the subdomain name probably wouldn't be effective otherwise it is also an option.
You could keep user ID and user account_url in a separate table and cache that table so you don't hit the database for the vast majority of lookups.
My recommendation would be to keep the primary key the integer, index the account_url and identify a page load target time; say completing all database access and page rendering in under 1.500 seconds. When your site starts to respond over your threshold, then you can analyze your site to see where the actual problems lie and address them then.
In general, leave the database normalized as much as possible. If and when you can provably show (using metrics and actual measurements) that you need to denormalize for performance reasons, then think about doing that.
In this case, if you have a m-1 relationship between a domain and a user's account, you can effectively treat the domain as a user ID; you just have to join things in the right way. (and by m-1, I mean a single domain can only be "owned" by 1 user).
The key thing is that you don't need to get the user_id because you can get to it by joining the ACCOUNTS table as needed since it ties the domain to the user_id.
Lastly, to your question about using the domain as the primary key, you can do this, since a domain is required to be "unique", but you have a minimal overhead and much more flexibility by using a surrogate primary key.
You have two totaly separate issues. Mapping Subdomains and pages to a user is the easier of the two. The more difficult issue is "State". You need to create state database (or similar module) to keep track of which user is currently logged in and if they are still logged in when an update is received.
JZ touched on this in his comment. Don't confuse these two issues, they are separate and should betreated as such.
I have a table of users in SQL Server with all the contact details, personal details etc. When each user signs up to my website they will be given the option to opt-in to 5 different types of emails like:
I wish to receive emails about new things
I wish to receive the monthly newsletter
etc etc. I am trying to decide the best way to store this information in a database. My current thinking is to have a seperate table with 5 columns (one for each opt-in) and the value being a bool/bit value.
Since the information wont be required regularly, it will only be required when we want to send mail to user. Are there any better ways / best practices for doing something like this?
The problem with your proposed design is that it becomes difficult to add new email types in the future; you only have 5 now, but what happens when you add a sixth or seventh?.
Instead, I would propose something like:
User Table:
UserID (Primary Key)
User Attributes
EmailTemplate Table
EmailTemplateID (Primary key)
Email Template Attributes
UserEmailTemplates
UserID
EmailTemplateID
You can easily add new templates, and associate them with users.
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?