I have a Users table that belongs to a Role, and has one Server or no one (depends on role), but should to have a Server table with user_id field or should I put all Server info in Users table and when the role hasn't Servers, the fields will be null?
I just think that if a User have one server (or not), this shouldn't be a new row in Servers table, maybe if the user_id field be unique, then it will be correct, I don't know.. I'm confused.
Just explain to me which is the best way to build this thing.
-- edit
This is my tables actually
Roles
id (PK) | name
1 | Administrator
Users
id (PK) | role_id | name
1 | 1 | Juliano
Servers
id (PK) | user_id (UNIQUE) | name
1 | 1 | Test
I don't know.. in servers, user_id should be UNIQUE or PK?
ONE TO ONE Relation , Then put the server in the user table.
Users Table:
ID(Pk)
RoleID
Name
ServerID
Related
EDIT: I think I worded this wrong. Please read foreign keys as foreign key constraints. I realize I need the client id in the address table, etc.
I have a client table.
id | pref_name | full_name | business_name | etc . . .
I realized the client can have multiple locations/addresses so I have an address table.
id | client_id | name | address1 | address2 | sub_area_id | area_id | province_id | country_id | postcode | etc . . .
Then I realized clients can come from multiple countries so I added:
country table
id | country | code (ISO-2A)
province table
id | name | country_id
area table
id | name | province_id
sub area table
id | name | area_id
So now I realize that I don't need all of sub_area_id | area_id | province_id | country_id in the address table.
From sub_area_id I can get the rest with a join query, however, there will not always be a sub area id. There WILL always be an area id. I guess I do need sub_area_id | area_id but can remove province_id | country_id from the address table
What I am not sure of is do I need foreign keys for the country, province, area, sub_area table with each other?
It seems that if a country is deleted so should all relating data in the other tables, but I am pretty sure that a country will never be deleted. Same for provinces, areas, sub_areas. Is it a waste of time implementing foreign keys?
Also a client might be disabled (not deleted because it would affect historic data) so can a foreign key also disable the client addresses, or is it just not necessary to disable them? Again, its probably not best to delete them as the client may resume later on.
Any suggestions for improvement on my structure?
TIA
Yes definitely you need foreign key to refer the address of client. if you have not the id of the client in address table, you have no way to retrieve address of your client from address table
I have 3 type of user roles: Patient, Doctor, Pharmasist
And Tables:
Users
id | name | surname | username | password | etc..
Roles
id | name
Patient
Doctor
Pharmasist
users_roles
id | user_id | role_id
And I want to implement tables such as: doctor_info, patient_info, pharmasist_info.
For example:
doctor_info
id | experience | qualification | user_id
What relationship should I use to tie users with doctor_info, patient_info, pharmasist_info and how to implement it correctly?
Assuming all id column from each table is primary key.
users:
id, name, ...
roles:
id, name
users_roles:
id, user_id, role_id (make user_id UNIQUE key, so 1 user can only have 1 role)
doctor_info:
id, user_id, ... (make user_id UNIQUE key as well, so 1 user can only be 1 doctor)
patient_info:
similar to doctor_info
pharmasist_info:
similar to doctor_info
(OPTIONAL) If 1 user has 1 role and 1 role is belonged to many users, you could remove users_roles table completely, and just add role_id in users table.
One issue is that you can have: 1 user can be a doctor, a patient and a pharmasist altogether with your table structure. You'll have to add some validation in your code to make sure it won't happen.
I'm a beginner concerning coding and especially SQL and PHP.
I deal with app. 120 users.
The users can acquire app. 300 different collectible items.
When a user acquires a specific item, I would like the ID number of that particular item to be stored in the row of the user who acquired it, so that there is some information about what items the user already has (and to avoid duplicate items in his possession).
Is there a good way to store such information?
Is it even possible to set a column type to array and store it there?
Please note: I'm not lazy and I've been digging around and searching for the answer for 2 hours. I couldn't find a solution. I know of the rule that one should insert only one piece of information into one cell.
MySQL does not support storing arrays. However, you can use a second table to emulate an array by storing the relation between the users and items. Say you have the table users:
CREATE TABLE users (
user_id SERIAL PRIMARY KEY,
...
);
And you have a table defining items:
CREATE TABLE items (
item_id SERIAL PRIMARY KEY,
...
);
You can relate what items a user has using a table similar to user_items:
CREATE TABLE user_items (
id SERIAL PRIMARY KEY,
user_id BIGINT UNSIGNED NOT NULL,
item_id BIGINT UNSIGNED NOT NULL,
...,
FOREIGN KEY (user_id)
REFERENCES users (user_id),
FOREIGN KEY (item_id)
REFERENCES items (item_id)
);
Then, to determine what items user 123 has acquired, you could use JOINs similar to:
SELECT items.*
FROM users
INNER JOIN user_items
ON user_items.user_id = users.user_id
INNER JOIN items
ON items.item_id = user_items.item_id
WHERE users.user_id = 123; -- Or some other condition.
I assume you have 2 tables for example, users and items. To control which user already has a specific item, i would create an associative table, including the UserID from users and ItemID from items. This way you can now check in your user_items table if the user already has this item.
Here is a small example:
users (UserID is PK):
+--------+----------+
| UserID | UserName |
+--------+----------+
| 1 | Fred |
| 2 | Joe |
+--------+----------+
items (ItemID is PK):
+---------+----------+
| ItemID | ItemName |
+---------+----------+
| 5 | Book |
| 6 | Computer |
+---------+----------+
user_items (ItemID referencing items.ItemID, UserID referencing users.UserID):
+---------+--------+
| ItemID | UserID |
+---------+--------+
| 5 | 1 |
| 6 | 2 |
+---------+--------+
favorite
If I'm designing the backend for a messaging app that allows group texts and has the following structure:
Message Table
message id | creator | message data | date created
Conversation Table
conversation id | creator | date created
ConversationtoMessage Table
conversationtomessage id | conversation id | message id
ConversationtoUser Table
conversationtouser id | conversation id | user id
Does it makes sense to have the creator of the conversation column in the conversation table, or is that redundant information given that the creator will also be linked in the conversationtouser table
I think it can be done using two tables only:
users
id (unique id)
username
name
created
messages
id (unique id)
user_id
type (1 for individual messages, 2 for group messages)
message_identifier ( unique id for particular conversation)
message_text
created
I'm having trouble modeling a particular database structure I'm working on. To be short, considering the following:
A webpage can have one or more threads on it
A thread consists of one or more comments
Comments can have one or more complaints filed against it
Complaints can also be filed against the thread as a whole
Complaints can also be filed against the page
I can't quite figure out how to model this at the DB level. The first three are easy:
webpage
----------
id
name
thread
---------
id
page_id
name
comment
--------
id
thread_id
name
But if I wanted a single table of complaints, how would one model that? I don't think you would want to do:
complaint
----------
id
page_id
thread_id
comment_id
If you ever added a new object type, like picture, you'd have to add more columns to the complaint. Is there a better way to do this, or is at as good as it gets?
Thanks in advance,
- Anthony
I would create the complaint as an entity in it's own right, then have link table between all the different things it can be associated with.
So, I'd have the following tables ...
complaint
compliant_comment_link
complaint_thread_link
complaint_page_link
This is a slightly different variation on Waleed's solution. As with all things like this, there are many ways to solve it :)
The advantage of this approach is that you can have foreign keys to maintain data integrity. The disadvantage is that whenever you need to have complaint against a new "thing" you will need a new link table, but I suppose you'd have to create a new "thing" table anyway.
One solution off the top of my head is to have a table:
ObjectType
-------------------
| id | name |
-------------------
| 1 | Webpage |
| 2 | Thread |
| 3 | Comment |
-------------------
Then your complaint table can be as follows:
----------------------------------------
| id | object_type_id | objectid |
----------------------------------------
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| 3 | 2 | 1 |
---------------------------------------|
Of course this could add additional work later on when querying the complaint table and joining with the others, but that all depends on what you want to query.
Another approach is to have a new entity table that has a supertype/subtype relationship with the 3 tables (webpage, thread, comment):
entity
----------
id (PK)
webpage
----------
id (PK)
name
FOREIGN KEY id REFERENCES entity(id)
thread
---------
id (PK)
page_id
name
FOREIGN KEY id REFERENCES entity(id)
comment
--------
id (PK)
thread_id
name
FOREIGN KEY id REFERENCES entity(id)
complaint
----------
id (PK)
entity_id
FOREIGN KEY entity_id REFERENCES entity(id)
This way, creating of a new webpage (or thread or comment) or deleting one will be slightly more complicated (inserting or deleting a new row in two tables than one.)