This is more of a question on best practice/efficiency optimization, while also helping me to unstick myself.
I need to make a database that simulates a video game company. I have the project entity along with a assigned employee roster for that specific project, and employee entity with foreign keys relating to them from the project roster. I have to add different pay types such as a contractor, an intern, and a full time employee. Along with this I have to divide the employees themselves up into four separate groups to indicate if they are a programmer, an artist, a designer, a tester, or a producer. What might be the most efficient way to handle this while maintaining database query flexibility?
An idea that I had was to attempt to make a bridge entity for both pay types and employee types, but I got stuck thinking I might need to have foreign keys to each respective type table from the pay type bridge, or the employee type bridge, and that would simply be redundant on the query side, along with it yielding the wrong individuals upon a query.
Is there a way I could make a composite key that might look at an attribute of an entity, and assign them as a member of the indicated employee type?
For example:
emp_ID lname fname assigned_project FK_pay_type_ID
123456 Shelly Mary 21 65(contractor)
emp_type
designer(this could be read and a script could assign her to the designer table?)
To Give an idea of what I am thinking of doing here is a couple of tables I mocked up in Visio:
Visio Image Here (I really have to have arbitrary site points just to post an image that clarifies my question? Really?)
Project Project_Roster Employee
FK_projectState ----> PK_projectRoster_ID <list employee credentials here>
PK_Project_ID FK_Employee_ID ------>FK_assignedRoster_ID
projectName FK_payType_ID (goes to bridge)
launchDate FK_EmployeeType_ID(goes to bridge)
Employee_PayType_BR
PK_payType_ID (pointed to specific type depending on assigned?)
FK_Employee_ID
description
amount_Offered
amount_paidToDate("salary" if full time)
#Not sure how to get here
PayType - Contractor
PK_Contractor_ID
FK_Employee_ID
parent_company
skill_set(list | array)
PayType - Intern
PK_Intern_ID
FK_Employee_ID
Perhaps there is a simpler way, and I am just missing it, and in that case I apologize for my ineptitude.
Related
I am creating a database for a community to store details of all their members along with those members' relations with each other.
For Instance: There is a family of 4. Mother, Father, Son and Daughter. The Son gets married to a girl from another family in the same community (Their data is also in the same database). The newly married couple has a new member soon. Also they need to add their grand parents to the database at a later stage (Parents of both the Mother and Father in this case).
What would be the best way to create a schema for such a database.
I have a schema called member_details that'll store all community members' data in a single table something like this.
member_details: ID | Name | Birthdate | Gender | Father | Mother | Spouse | Child
All members would have relations mapped to Father,Mother,Spouse,Child referenced in the same table.
Is this schema workable from a technical pov?
I just need to know if my solution is correct or is there a better way to do this. I know there are a lot of websites storing this kind of data and if someone could point me to the right direction.
I'd advice you to use two tables. One for members of community and one for relations beetween them. Something like this:
Members:
ID | Name | Birth | Gender
Relations:
First Member ID | Second Member ID | Relation
Where you use IDs from first table as foreign keys in second. That way you'll be able to add more relations types when you need it. By the way, I'd add a third table to store relation types, so it can work as a dictionary. Same thing for genders.
As usual, "it depends".
The first question is "how will you use this data?". What sort of questions do you expect the database to answer? If you want to show a person's profile with their relationships, that's pretty easy. If you want to find out how many children a person has, or who is the grandfather of a person, or the age of someone's youngest child, that could be a little harder.
The second question is "how sure are you these are the only relationships you want to store?" Perhaps you also want to store "neighbour", "team member", "engaged_to" - or maybe you need to store that information later on. Maybe you need to take account of people getting divorced, or remarrying.
The schema you suggest works fine for most scenarios, but adding a new type of relationship means you have to add a new column. There are no hard and fast rules, but in general it's better to add rows than columns when faced with events in the problem domain. Asking "who is this person's grandfather" requires a couple of self joins, and that's okay.
#ba3a suggests splitting the information about people from the information about relationships. This is much "cleaner" - and less likely to require new columns as you store more types of relationship. Showing a person's profile requires a query with lots of outer joins. Finding a grand parent requires self joins on the "relations" table.
I have 2 kinds of users:
Employees
Recruiters
Recruiters can make vacancies.
A vacancy can have requirements and an employee also has/or doesn't have these requirements:
Transportation(car, licence, ...)
Language(English, Dutch, French, German, ...)
Jobterm(employee, freelance, student, intern, ...)
Sector (logistics, retail, cleaning, ...)
Regimes (fulltime, parttime, holidays, weekends, ...)
In my current database structure I have tables for all 5 of these requirements and foreign keys.
My question is; everytime I'm loading a Vacancy, it needs to get the FK value out of all these models, and thus, loading 6 models every time I want to display something in my view.
Isn't it more efficient since they are only 1 column tables to put the values directly into the models and make sure that front-end wise the user cannot enter any other values?
Or is there another way to reduce load-times (or is this a non-issue?).
Thank you.
I'm new to the forum, and I've tried searching for an answer but I can't find specifically what I need. Here is the deal. For a collage project I have to make a car rental web application. I've come up with an idea what should it do and for that I've created my ER model. But I'm not sure if it's good. The thing is not to do very complicated application, but to cover one RAD tool. I've ended up with Iron Speed. Here is the idea of the application.
Customer can come to website of car rental, and make a reservation, beside other things he can choose start date, end date, and car.
Employee can edit, and see all the reservations, and also make a reservation if customer comes personally to "office". He can also add new cars to database (type of car + model etc.) and make a bill for each reservation.
Administrator can add new employe and everything else (but that's his main thing let's say).
Table USERS has all the information about employees and administrator, and roles has roles in it, and they need to have a bridge table (this is needed because of the RAD tool to make user roles permissions).
Information about customers won't be needed separately (this can be a bad thing but let's leave it that way), and we have their information in REZERVATION table.
NOTE - I know it would be logical to connect employee with reservation (one to many) but that gives me the problem that customer needs to select employee when making reservations, same with car adding, it's stupid to select employee to add car... I mean its logical that someone needs to put car into database. For bill it is logical so I know who made it.
Car type and car are connected with reservation that way so I can make filtering type - > model later in drop down menus.
Link to jpeg: http://dl.dropbox.com/u/50541281/SnapShot_121124_220841.jpg
Link to mysql workbench file: http://dl.dropbox.com/u/50541281/car%20rental.mwb
I would really appreciate it if someone who knows can modify it as needed, or put some bridge tables if needed. Or just type notes here so that I can adjust my schema myself.
Just to add, this is only let's say need to see version of ER model since I've just translated it from my language to English, so all attributes, types, etc are not there.
In this situation you may be best using a join during the sql statement to get the information. Assuming the employee doesn't have anything to do with this account until later in the process (after booking the car) you should leave it to the other interface. When the cars are booked an employee should log in and check, if they process the order then add the EmployeeID to the table then. Leave it without relationship, it seems messy but it is a quick solution.
In my program, I need to make an organization chart starting with individuals and grouping them under a manager, then group those managers under senior managers etc... How do I do this with regards to the database?? This is a many to one relationship - which I thought was illegal and impossible - and would be like starting with the child table - individuals - before creating its parent - manager.
If someone can help point me in the right direction to design my database I'd really appreciate it!!
----EDIT----
Here's a more detailed explanation of my problem:
Let's say a user of my program starts by entering in 35 individuals they'd like to use on some project they're going to work on. Now, there are several possible management positions that can be created and have employees/other (lower) managers assigned to those. The user doesn't HAVE TO create any particular position, but can pick and choose and assign however they like. The only constraints are there will always be a top manager - let's call him the President - and that he SHOULD (but doesn't HAVE TO) only assign 5-10 people to any given manager (president included). So in this example we are starting with 35 individuals and a President. Now we start grouping the 35 individuals into teams and assigning one of them as manager. Say the user decides to have two teams of 6, two teams of 9, and one team of 5 - each of these groups has one of its individual members assigned as manager of that team. So now we have 5 teams, each under its own manager, and those five managers would now be assigned to the President. The program would let this go but warn the user that the number of individuals under a manager in the last team is less than 5 (is only 4). So the user can now (or at ANYtime) go back and change the organization. So let's say he wants to fix this issue and changes up the teams. So he breaks up one of the two teams of 9 and assigns one individual to the team that was short a person. This makes a final count of 3 teams of 6 (5 individual members and one manager), one team of 9 (8 ind and 1 mngr), and one team of 8 (7 ind and 1 mngr) and all 5 team managers are assigned to the president.
Only in real life this can get broken down much further - nests with many more levels of management. How can I do this?
Is Joe Hopfgartner's answer below still valid? Can I just make a "role" column, even though the role would be assigned later (after the row is initially created)? Or changed at any time? Can this self-referencing foreign key be null? (as it would be in the case that no manager has been assigned yet) Or should I move the individuals to a separate "team" table after they've been assigned to a team and move the managers to a "manager" table once they've been assigned as a manager, then add a foreign key for the team table referencing the manager table?
Also, I am using MySQL, so does that fact that you cannot use self-referential ON UPDATE CASCADE or ON UPDATE SET NULL operations affect my particular case (since users will no doubt often be changing the assignments)?
Thank you so much for helping me with this!!!
if one individual can only have one manager, just introduce a "parent person" id field or put managers in a seperate table.
if not, create another table for a relation like "person_has_manager" that assigns a person to a manager.
you can also put managers and persons into the same table and introduce a "role" field, but this can be tricky when using foreign key constraints if you want to ensure that only manages can have persons assigned to them.
to solve this problem you can introduce a "person_is_manager" table that links person to their job as manager, and persons can be linked to be managed by that manager. this ould look like this:
persons
-> person_id (primary)
-> name
-> etc
managers
-> person_id (primary, linked to person_id in persons)
person_has_manager
-> person_id (primary)
-> manager_id (primary, linked to person_id in managers table)
It's a tree. You can use a single table with a parent_id field, to indicate which record is the parent to the current one.
I have an Access application, in which I have an employee table. The employees are part of several different levels in the organization. The orgranization has 1 GM, 5 department heads, and under each department head are several supervisors, and under those supervisors are the workers.
Depending on the position of the employee, they will only have access to records of those under them.
I wanted to represent the organization in a table with some sort of level system. The problem I saw with that was that there are many ppl on the same level (for example supervisors) but they shouldn't have access to the records of a supervisor in another department. How should I approach this problem?
One common way of keeping this kind of hierarchical data in a database uses only a single table, with fields something like this:
userId (primary key)
userName
supervisorId (self-referential "foreign key", refers to another userId in this same table)
positionCode (could be simple like 1=lakey, 2=supervisor; or a foreign key pointing to another table of positions and such)
...whatever else you need to store for each employee...
Then your app uses SQL queries to figure out permissions. To figure out the employees that supervisor 'X' (whose userId is '3', for example) is allowed to see, you query for all employees where supervisorId=3.
If you want higher-up bosses to be able to see everyone underneath them, the easiest way is just to do a recursive search. I.e. query for everyone that reports to this big boss, and for each of them query who reports to them, all the way down the tree.
Does that make sense? You let the database do the work of sorting through all the users, because computers are good at that kind of thing.
I put the positionCode in this example in case you wanted some people to have different permissions... for example, you might have a code '99' for HR employees which have the right to see the list of all employees.
Maybe I'll let some other people try to explain it better...
Here's an article from Microsoft's Access Cookbook that explains these queries rather well.
And here is a somewhat chunky explanation of the same.
Here's a completely different method (the "adjacency list model") that you might find useful, and his explanation is pretty good. He also points out some difficulties with both methods (when he talks about the tables being "denormalized").