I have three tables in my database: Contacts (master table), Users and Staff. The Contacts table has a primary key that is referenced as a foreign key from the Users and Staff tables.
Contacts
ContactID (Primary Key)
First Name
Last Name
Email
Users:
ContactID (Foreign Key)
Username
Password
Staff:
ContactID (Foreign Key)
Position
Comments
Pulling data from these tables is fairly simple with INNER JOIN and depends what data you need from the Users or Staff table. Updating and inserting new records is something that I'm not sure which way to approach.
Since the Contacts table is my master table and holds unique ID's but at the same time is shared between Users and Staff, I'm not sure about this situation.
Let's say I want to enter new user record. I need to enter First, Last name and email into the Contacts table, and User Name and Password into the Users table. At the same time I have to check if First, Last name and email already exist in the Contacts table, since maybe this Contact record has been previously entered for a Staff record.
I'm not sure how to prevent duplicates but at the same time there might be user or staff with the same name. Should I limit/filter by email and not let them enter the records if the email already exist in contacts table? Or is there a better way to handle this?
The whole point of having three tables is to prevent redundant data since User might be a Staff, but Staff might not be a User if that make sense. If anyone can help me pick the best approach please let me know. Thanks
You have to start by using a SELECT query and whatever business rules you want to test to decide if you will perform the INSERT at all, or UPDATE an existing record instead.
Then if you are going to INSERT, you have to INSERT into Contacts first, get the newly inserted ID, and then INSERT into the other two tables.
Related
Let's assume I am building the backend of a university management software.
I have a users table with the following columns:
id
name
birthday
last_english_grade
last_it_grade
profs table columns:
id
name
birthday
I'd like to have a third table with which I can determine all professors teaching a student.
So I'd like to assign multiple teachers to each student.
Those Professors may change any time.
New students may be added any time too.
What's the best way to achieve this?
The canonical way to do this would be to introduce a third junction table, which exists mainly to relate users to professors:
users_profs (
user_id,
prof_id,
PRIMARY KEY (user_id, prof_id)
)
The primary key of this junction table is the combination of a user and professor ID. Note that this table is fairly lean, and avoids the problem of repeating metadata for a given user or professor. Rather, user/professor information remains in your two original tables, and does not get repeated.
If I wanted to make a database with subscribers (think YouTube), my thought is to have one table containing user information such as user id, email, etc. Then another table (subscriptIon table) containing 2 columns: one for the user id and one for a new subscriber's user id.
So if my user id is 101 and user 312 subscribes to me, my subscription table would be updated with a new row containing 101 in column 1 and 312 in column 2.
My issue with this is that every time 101 gets a new subscriber, it adds their id to the subscription table meaning I can't really set a primary key for the subscription table as a user id can be present many times for each of their subscribers and a primary key requires a unique value.
Also in the event that there's a lot of subscriptions going on, won't it be very slow to search for all of 101's followers as all the rows will have to be searched and be checked for every time 101 is in the first column and check the user id (the subscriber to 101) in the second column?
Is there's a more optimal solution to my problem?
Thanks!
In your case, the pairs (user_id, subscriber_id) are unique (a user can't have two subscriptions for another user, can they?). So make a compound primary key consisting of both fields if you need one.
Regarding the speed of querying your subscription table: think about the queries you'll run on the table, and add appropriate indexes. A common operation might be "give me a list of all my subscribers", which would translate to something like
SELECT subscriber_id FROM subscriptions WHERE user_id = 123;
(possibly as part of a join). If you have indexed the user_id column, this query can be run quite efficiently.
A Primary Key can be made of two columns, subscribe and subscriber in your case. And since search will only be on integer value, (no text search) it will be fast.
more informations here : https://stackoverflow.com/a/2642799/1338574
I am basically designing a web checklist. The process is as follows: User logs in, selects the "Job Name" for a list, clicks on it, goes to next page, selects "Procedure list" from a list, clicks on it, goes to next page, there he sees a checklist where he can basically add comments, and click check box on individual listings.
I know how to code most of it, but at the moment i'm trying to figure out how to setup the
relationships + what extra tables to add to hold the information.
General layout I have at the moment:
Table: User_list
User_ID
Username
Table: Job_list
Job_ID
Job Name
Table: Procedure_List
Procedure_ID
Procedure Name
Job_ID
Table: Check_List
Job_ID
Checklist_ID
Description
Job_ID -> Procedure_ID -> Checklist_ID is one to many... but how to add the user list in order to store all the changes done by the user.
So you can basically have one page where you see:
Job Name
Procedure
Checklist done
and all the details done by the users.
I'm assuming the relationships are Job 1:m Procedure 1:m Checklist. And a user may choose any number of jobs. The combination of Job/Procedure/Checklist is chosen by the user. For example, I assume a Job may have 10 associated procedures and the user selects 1 or more of these. Same for Procedure: A given procedure has certain checklists associated with it and the user may select any number of these checklists.
Use "join tables".
User_Job table. A user may be associated with any job or any number of jobs. The user_ID and job_ID go into the User_Job table. Make the primary key the User_ID + job_ID.
Job_Procedure table. Put the User_Job key (both columns) and procedure_id in this table. Make the primary key User_ID, Job_ID, Procedure_ID
Procedure_Checklist table. Put the Job_procedure key (all columns) & the checklist_id in this table. Make the primary key a compound using all the columns.
Primary Keys thoughts
A sequence number for a primary key for each table will limit the number of columns in the related tables. However this key has no real meaning and if you're looking at the Procedure_Checklist table, for example, you cannot tell which job & user without querying the other tables - PITA. It's also meaningless to sort such a key. And it does not prevent duplicate rows.
I have a user table with userid (pk), password, usertype.
I have another table student with stdid (pk), stdname, stdaddress.
I have a third table faculty with facid (pk), facname, facaddress.
What I want to do is populate the user table with the pk from either student table or faculty table.
How do I implement this in SQL Server 2005.
Can someone help me?
Edited Below
In my database, the student and faculty table are already implemented as part of another module. I need to implement the authentication part over LAN to be able to be accessed from anywhere, so I can not restructure that part. So I am using the user table with userid (username) and password in that table.
The userid is either stdid or facid and also the pk of the user table.
What you have is a bad design. You do not want to use one or the other other PK as the PK in a table. This cannot every work. What happens when you try to insert student 10 (who is Joe Jones) but faculty 10 (Mary Smith) is already in the table. Well, the insert would fail becuse of the unique requirement of a PK.
If all studetns and faculty are always users, then userID is the PK and FacultyId and StudentID are the FKs to that table not the reverse.
insert into user_table (select facid as userid from facultaty_table union select stdid as userid from student_table)
this will leave column password and usertype as null otherwise it pumps up userid_table with all the PKs from the others
What are the data types of the keys? Is there a guarantee that they're going to be unique across both the student and faculty tables?
This seems like it's going to be a difficult design to work with over time. Maybe try moving the central focus from the "person" tables to the user table and assign roles from there? Something like this:
User
------
Id
Password
UserType
(where's the username?)
UserInfo
------
UserID
Name
Address
Role
------
Id
Name
UserRole
------
UserID
RoleID
(The Role table would have at least two records, one called "Student" and one called "Faculty", but could allow for more roles as well.)
There are a few benefits here:
You need only store names and addresses in one place, rather than duplicate the model across different roles.
A user can have multiple roles. For example, a faculty member could take some classes and be a "student" for a while. A grad student can teach some classes and be a "faculty member" for a while.
New roles can be added without having to change the data model.
I am building my own CRM access database that will contain a list of contacts. I would like to have an opportunity reference one contact as an employee, and another as the customer. Is there a way that I can add employees using their internal user ID (always 4 digits) and autonumber customer contacts?
I don't plan on building forms until I am comfortable that everything is working properly in table view.
You cannot assign an ID to an autonumber field. I might suggest adding an employeeID field to your contacts table that would have the employee ID number. The contact ID would still be an autonumber, so in essence they would have two IDs, but their employeeID would need to be stored in a different field.
You can try something different, but you will likely run into a duplicate ID at some point. Use a seperate table for autonumber Customer IDs. When adding a customer into your contact table, you "insert" a new record into the separate customer ID table to get the autonumber ID. If you're inserting an employee, just use the EmployeeID as the contact ID. So you need to be very careful when mixing two ID systems. It's best to use 1 ID and then use the other ID in some other field.
Consider using two tables, one for contact fields and another for employee-specific fields. Put your AutoNumber field in the contact table, and put the employee id in the employee table. In the employee table, use a foreign key that refers to the AutoNumber field in the contact table.