I have following tables in my Database:
Student (student_id, email, name, ...)
Course (course_id, course_name, ...)
Enrollment (student_id, course_id, marks,...)
I Want to implement this functionality:
When admin want to search list of all students in particular city,
the list is displayed as HTML table.
This can be implemented by just querying student table.
When admin click on any row (from the table we have displayed in 1.)
then admin should see list of all courses the student has enrolled
in.
My question is how should I implement this?
I can think of following ways:
Way 1:
https://stackoverflow.com/a/45135144/3494107
I need to have some way to identify which row admin has clicked, for this I can pass the student_id also in the table in result for 1 (display list of all student) but as student_id does not convey any information to admin about student I can just hide it in data-* attribute of <tr> or in <a href=/enrollment/${student_id}> so that I can use this to identify which row admin has clicked. Some of my friend told me that I should not expose surrogate key, this is bad for security. So is there any way I can associate this student_id to table row but hide from the user or it is OK to expose surrogate key content to user?
Way 2: I can create a temporary table containing all student from particular city in DB and assign the row ID to it. Now in result I can add this row ID for each row into data-* attribute. This row ID does not convey any information about what is actual student_id and I can use this row ID to query temporary table to get actual student_id which I can use to search in enrollment table. Now I need to delete this temporary table when user navigate away from current page (go to other functionality), now how should I detect when user have moved away from this page?
I want to understand what security issue I can have if I expose surrogate key to user?
No security issues as such if you expose the student_id but at business point of view it's not much acceptable.
If these tables are only viewed by admins then it is not a problem in either way.
If these are viewable by even by a guest then better not expose the student_id. Not for the security of your database but for the security of your business. It might expose your strength and weakness.
You can use student_registration_no instead. It might be slow, considering a VARCHAR entry, but not humanly detectable.
Related
I am working on a database which as a user table and a party table. A user can go to many parties and the party can host many users. So this is a many-to-many relationship. But since its not possible to have a many to many relationship between two tables, I created a joiner table called 'user_party' table. Now I am not sure what goes in the party table and what goes in the user_party table. For example, user table has basic columns like user_id, user_name, user_email, etc. and party table has information like party_description, party_time, party_location, etc. Should these party table values go to user_party table instead? What values should the joiner table include and what goes in the party table?
The joiner table should be here to maintain the relation between a particular user and a specific party, and in your case, not more.
Before all, the party should be uniquely defined with a party_id primary column. Then, a user_party table could be define with only two columns: a user_id and a party_id.
So, the join would involve 3 table rows uniquely identified:
One from the user table (identified by the user_id and storing all users details such as first_name, address...)
One from the party table (identified by the party_id and storing all the related info like location, start_datetime...)
One from the user_party(identified by the t-uple [ user_id, party_id])
The user_party table could only embed some data which are meaningful for single occurrences of the [ user_id, party_id] t-uple itself, such as the number of beer cans brought to a particular party :)
Eventually, these data could be externally stored into a specific table in order to keep only the relational aspect there and the t-uple extended with another key.
According to the underlying DB engine, the definition may go one step further, with the user_id and party_id columns of the user_party table declared as foreign keys, and additional drop and update triggers to handle automatic data binding across related tables.
I think I have a solution for you. As I understand from your description you need to change your schema a little bit, and your table should be look like below.
User(user_id, user_name, user_email);
party (party_id,party_description, party_time, party_location);
user_party (id,party_id,user_id);
hostuser_party (id,party_id,user_id);
Note: hostuser_party table is required if a party hosted by multiple users. If party always hosted by one user then you can add host_id(User_id) column in party table.
I'm creating a database that will be used to keep track of maintenance performed on equipment in a nursing home. I'm using MS Access 2010, and I'd say my skills are somewhere between novice and intermediate, almost entirely self-taught for this project.
The database structure is as follows:
tblAssetTypes:
TypeID (PK),
MaintenanceSchedule,
EquipmentType,
EquipmentSubgroup,
MaintenanceTime,
TasksRequired
tblUniqueAssets:
UniqueID (PK),
StorageLocation,
TypeID (FK)
tblPrevMaintRecord:
ID (PK),
UniqueID (FK),
DatePerformed,
TimePerformed,
MaintenanceComments
The UniqueID will be an identifier created by maintenance people, usually as four letters and then three numbers. I'm currently using "test001", "test002", etc.
I have a form that allows users to enter the UniqueID that has been assigned to an asset, select what kind of equipment it is, and where it is stored.
I'm currently creating another form which I want users to be able to select from a list of pre-existing UniqueIDs and then change the location that is stored in the table. However, as it is currently set up, every time I select a UniqueID from the combobox on the form, I get the following error. This error comes up after I have selected an UniqueID, and then if I try to do anything further, such as saving the record or even trying to close the form.
The changes you requested to the table were not successful because
they would create duplicate values in the index, primary key, or
relationship. Change the data in the field or fields that contain
duplicate data, remove the index, or redefine the index to permit
duplicate entries and try again.
I'm sure I probably need to give more information but I'm not sure what will be needed so I'll edit as needed.
How can I update the location information stored in tblUniqueAssets for a UniqueID value that already exists? Surely I wouldn't need to delete the record first and then create a new one with the previous UniqueID?
I need to make a user table in an education database where a user can have the following profiles:
1. Admin
2. School Admin
3. Tutor
4. Student
5. Parent
6. School Teacher
Now, the question is weather to make separate tables for each profile and use a key in the user to table to link with profile table or keep all in one and add a profile key to identify the type of user. Everyday new users are added in the database so its a growing database.
The queries which are run to fetch the data are specific to the profile. For example, the data will be fetched for one profile at a time. But, what about the cases where we need to get all the teachers of a student or all students of a teacher? In that case I will have to store the id of the student in the tutor and teacher table. What is the optimized way of going about it?
I will suggest to make separate tables for profile and use a key in the user to table to link with profile table (if profiles are pre-configured)
if profiles are dynamic then you have to take care in your application like check profile exists or not, if not exists then first insert into profile table and then insert into user table. This may affect INSERT performance.
to get all the teachers of a student or all students of a teacher, you have to use self-join
How do I link or add the field with all my users called "username" from my main table to another table so I can run checks and compare values without having to add a ton of rows to my main table? This would be a much cleaner and more organized setup.
Table called login_users. This is my main table that stores their basic information
username email password
Anthony user#email.com
Josh user#email.com
Tsuyoshi user#email.com
Table 2 called badge_status. This table will hold their status with whether or not they have unlocked an achievement on my site. I want to bring in the usernames.
username badge1 badge2
Anthony locked unlocked
Josh unlocked locked
Tsuyoshi unlocked locked
Also, could table 2 automatically be updated with a new user when they sign up since all new sign ups are imported into the first table. As a side note, I am using phpmyadmin.
Thanks for any help with getting this set up. Very much appreciated.
I think you should normalize your data by using the following schema instead:
login_users [Table]
username
email
password
badges [Table]
BadgeId int PRIMARY KEY
BadgeName
... (any other relevant columns)
users_badges [Table]
username (foreign key constraint to username column on the login_users table)
BadgeId (foreign key constraint to BadgeId column on the badges table)
This will allow you add as many badges as you want without having to ever change your database schema or scripts.
I don't really understand why you are separating out these tables. In theory, there is a one-to-one relationship between the two. Your query "could table 2 automatically be updated with a new user when they sign up since all new sign ups are imported into the first table" further supports the argument why splitting these tables simply creates unnecessary overhead.
Other sources of overhead include overly complicated JOINs to get the data out and the need to add an additional unique constraint on badge_status.username as well as a foreign key.
If you truly wish to separate out these tables, I would suggest the following setup instead which makes querying for specific badges and adding new badges very easy:
login_users: username, email, password, ...
badges: id, name, description, ...
users_badges: username, badge_id, status, unlocked_date, ...
Apologies if I wasn't able to describe the problem accurately in the title. My scenario is as follows.
My site operates as a platform to connect vendors and buyers. Vendors list down the goods/services they have available and buyers are able to purchase goods/services from them.
New buyer (user) registration is straightforward in that their information gets stored in users tables (users, user_profile, user_history etc.) tied together with a unique user_id. What I'm having difficulty wrapping my head around now is that I require vendors to register as well (for verification purposes,) and that vendors can also be buyers.
My users table is like so:
user_id <--- primary key
name
email
...
and a related table may look like so:
transaction_id
user_id <--- foreign key
date
amount
...
My initial thought for the vendors table:
vendor_id <--- primary key
user_id <--- foreign key
vending_name
registration_number
...
and a related table:
product_id
vendor_id <--- foreign key
name
price
...
My question is, would it be best to have this vendor_id to link up all the vendor-related tables or should I stick with using the user_id for everything?
Thanks.
It depends.
Think of this scenario, could a user ever become a vendor (or vice versa?) if so then it's best to plan your data models around a base user and add attributes or flags (in a separate table or field). This way, you can add/remove privileges.
i.e. Have a separate tables called "flags" "flagmappings"
//flags
flag_name <--- 'Vendor', 'User'
//flagmappings
user_id <--- foreign key
flag_id <--- foreign key
This structure gives you a few benefits:
For any given user you can search flagmappings and then determine what privileges a user might have.
All your login/authentication logic is the same for all users/vendors (i.e. you don't have to split/special case different tables if it's a vendor or a user, all the base information is in the same place).
If a user needs to become a vendor or vice versa you simply add that flag to the user.
If you need to create yet another type of user (i.e. administrator, manager, etc.) it's just another entry in the flag table.
If I were you, I would just stick with the users table for everything (as long as you don't have a gazillion vendor-specific fields). It just makes things cleaner. Then, you might have a 'is_vendor' field in the users table.
Or if you want to go even more sophisticated, you could implement roles with something like this:
users Table
id
firstname
etc...
groups Table
id
title
etc.
user_groups Table
user_id
group_id
Personally, I would go with the second option because it allows for more role-based permissions, such as admin, editor, moderator, buyer, seller, super-buyer, super-seller, etc.