A company is hired by another company for helping in a certain field.
So I created the following tables:
Companies: id, company name, company address
Administrators: (in relation with companies) id, company_id, username, email, password, fullname
Then, each company has some workers in it, I store data about workers.
Hence, workers has a profession, Agreement Type signed and some other common things.
Now, the parent tables and data in it for workers (Agreement Types, Professions, Other Common Things) are going to be the same for each company.
Should I create 1 new database for each company? Or store All data into the same database?
Thanks.
Since "Agreement Types", "Professions" are going to be same for each company, I would suggest to have a lookup table like "AgreementTypes" with columns such as "ID", "Type" and refer "ID" column in "Workers" table. I don't think new database is required, relational databases are used to eliminate data redundancy and create appropriate relationships between entities.
By imagining having one database for one company, it ends up with having one record in "Company" table in each database. "Administrators" & "Workers" are associated with that single record. And other common entities such as "AgreementTypes" will be in other tables.
So, if there is any addition/modification to agreement type, it is difficult to do it in all databases. Similarly, if there is any new entity to be linked to "Company" entity, again all databases needs to be revisited based on assumption that these entities belong to ONE application.
You should have one single database, with a structure something like this (this is somewhat over-simplified, but you get the idea):
Companies
CompanyID PK
CompanyName
CompanyAddress
OtherCompanySpecificData
Workers
WorkerID PK
CompanyID FK
LastName
FirstName
DOB
AgreementTypeID FK
ProfessionID FK
UserID FK - A worker may need more than one user account
Other UserSpecificData
Professions
ProfessionID PK
Profession
OtherProfessionStuff
AgreementType
AgreementTypeID PK
AgreementTypeName
Description
OtherAgreementStuff
Users
UserID PK -- A Worker may need more than 1 user account
WorkerID FK
UserName
Password
AccountStatus
Groups
GroupID PK
GroupName
OtherGroupSpecificData
UserGroups --Composite Key with UserID and GroupID
UserID PK
GroupID PK
Obviously, things will grow a little more complex, and I don't know your requirements or business model. For example, if companies can have different departments, you may wish to create a CompanyDepartment table, and then be able to assign workers to various departments.
And so on.
The more atomic you can make your data structures, the more flexible your database will be as it grows. Google the term Database Normalization, and specifically the Third Normal Form (3NF) for a database (Considered the minimum for efficient database design).
Hope that helps. Feel free to elaborate if you are stuck - there is a lot of great help here on SO.
Related
In a new database model that I am designing, I have a company table that has a contacts table related to it using a foreign key companyID field.
I have a branch table with PK branchId and FK companyId.
The problem is: Sometimes contacts can move from the company or branch they are in to a different one. And I need to know all the former companies and branches the contact was in.
What is the best way to do this?
I can't figure out anything that makes sense. If I insert another record into contacts with the different details, There will be a duplicate record, and if I just change the details, how will I know what the former details were?
I would suggest a table that joins your contacts table to your company table. This new table would have a contactsid, a companyid, a date (or date range, depending on your needs) and any other info that you would need to describe the relationship between the contact and the company. The contacts table would then no longer need an FK companyID.
Hello I have a Database like three tables:
Customer: Customer ID, Customer Name, Customer Surname
Product: Product ID, Product Name, Product Price
Now I have another table
CustomerProduct: Customer ID, Product ID
Here are all bought stuff standing, while taking the customer id and product id.
I just ask what kind of normalization of database structure this is?
Can you give me an explanation ?
Such a table, which handles many-to-many relationships by storing the two related primary keys (as foreign keys) is called by various names, but junction table seems to be the standard (I personally use association table).
Most relational databases do not handle many-to-many relationships natively - you need an extra table like this.
I Need to Design a database for a system where there's Customers and Vendors but they both are related to entity called Users where every user is either a customer or a vendor .
the problem is that Vendors are related to other entities that Customers aren't .
so how can I design such a database ?
The other entities will store the ID of the Vendor as a foreign key. And Vendors and Customers are not going to be in the same table anyway*, so it's not like the two have IDs that might be used at the same time for that.
Also, to add, the Foreign Key you require for User could be managed as an add/edit trigger if your DB of choice allows it. That way you can make sure that the Vendor id used for those related entities isn't a User ID linked to Customers. (...WHERE userid NOT IN (SELECT userid FROM users WHERE customer = TRUE))
* Customers and Vendors have different properties/fields so shouldn't be in the same table.
You could have Vendors and Customers have a relationship to a User table.
user
===========
userId
name
vendor
===========
vendorId
companyName
userId
customer
===========
customerId
source
userId
Then you can link to both customers and vendors from the same table, yet they can still share the same common data in the user table. In fact, a customer could also be a vendor.
Your question could be generalized as follows: how do I express subclasses in relational tables?
For the generic answer, see this:
https://stackoverflow.com/tags/class-table-inheritance/info
I am working on a database that has an existing Individuals table that every user type derives from. In other words, there are tables like:
Individual: FirstName, LastName, Email, <lots more>
Employee: IndividualId
Customer: IndividualId
etc.
Now, I want to add new type of user (WeirdPerson) that does not derive from Individual. (WeirdPerson has significantly less data associated with it than any Individual, and I really don't want to set practically every field in Individual to null for a WeirdPerson.)
I need a key field to use on a table that will have entries from WeirdPersons and entries from Individuals. This suggests map tables like so:
MashedupIndividuals: MashedupId, IndividualId
MashedupWeirdPerson: MashedupId, WeirdPersonId
I want MashedupId to be an auto-generated field. Since I'm using TSQL, an identity seems a good choice. Except that MashedupId is split across two tables. I considered yet another table:
MashedupIds: MashedupId
Set MashedupId to be an identity, and then make it a foreign key in MashedupIndividuals and MashedupWeirdPerson.
Is this the best way to proceed forward? How would you solve this?
EDIT: To clarify, the only piece of information I have for a WeirdPerson is an email address. I considered pulling the email field out of Individual, and then making a new GlobalPerson table with only GlobalPersonId and Email. The GlobalPerson table (or whatever better name I use) doesn't feel as natural as separating WeirdPerson as an entirely different type. However... I am willing to reconsider this position.
I would suggest a table to host data common to all people in your application. Then you could have additional tables for specific types of people and link them back to your common table.
tblPerson
PersonID (pk)
name, address, birthday, etc.
tblEmployee
EmployeeID (pk)
PersonID (fk to tblPerson)
Title, OfficePhone, Email, etc.
tblCustomer
CustomerID (pk)
PersonID (fk to tblPerson)
Other fields...
EDIT:
Here are some definitions more applicable to your question (and also more fun with these weird people). The key is establishing the data that weird people and normal people share and then establishing the tables/relationships to support that model. It might be necessary to move fields that are not applicable to weird people from tblIndividual to tblNormalPerson.
tblIndividual
IndividualID (pk)
Other fields for data applicable to both weird/normal people
tblWeirdPerson
WeirdPersonID (pk)
IndividualID (fk to tblIndividual)
NumberOfHeads (applicable to weird people)
tblNormalPerson
NormalPersonID (pk)
IndividualID (fk to tblIndividual)
FirstName (other fields applicable to normal people)
LastName
Etc...
You can use a uniqueidentifier field for your id. This is guaranteed to be unique across multiple tables. Use the NEWID() function to generate new values.
You could have a table with three fields, one of which is always null:
MashedupId, IndividualId,WeirdPersonId
or with an ID field and ID type (individual/weird)
I'm trying to model timesheets, billable hours, projects, users
Whats the best way to represent these in a database
Elaborating more on the question: My biggest predicament is how to keep date, hours, project together
One possible solution
User (PK id, name)
Project (PK id, name, FK user_id)
BillableHour (PK id, FK project_id, hours, date)
Thanks
Start with the reports you want and work backwards.
The minimal input unit is Activity, Duration, but if you use that minimum, you wind up with activities such as sri.attends.scrum.for.parisian.branch.of.client50.via.scype.from.home.to.discuss.installation.routine.of.zoom22, and your report code will have a lot of switch statements.
Presumably you will have at least one report with a name, an activity description, and a total time for a given time-period. If that's your only report, you can implement it as a four-field list: Worker (string), Task (string), Start (time), Duration (integer). If there's a report asking for all the activities ever allocated to a particular project, or one for all the time spent on activity-type X, or a report that allocates activities to particular clients, your design will benefit from more fields.
Perhaps you have a report that distinguishes installing.server.updates at the home office and installing.server.updates under active enemy gunfire in a warzone. If you have a "while.a.target" checkbox on your time-logging screen, that could be a real time-saver for your users.
It's worth learning about Normal Forms if you're not familiar with them. Saves you storing redundant data in your database (amongst other benefits).
http://databases.about.com/od/specificproducts/a/firstnormalform.htm
I can tell you from a very high level how I've done it for a very simple time keeping app. Although, this isn't necessarily the best way.
I don't have a handy ER diagram to share at the moment, but this is just a very basic starting point for a set of tables anyway.
User
ID PK
UserRole
UserID FK
RoleID FK
Role
ID PK
Name
UserProject
ID PK
UserID FK
ProjectID FK
HoursAvailable
Customer
ID PK
Name
Project
ID PK
CustomerID FK
EntryType
ID PK
Name (i.e. billable, non-billable, etc.)
Entry
ID PK
UserID FK
ProjectID FK
EntryTypeID FK
Hours
Date
TaskName (this could be further normalized, esp. if you want to have a bucket of tasks)
Description
I could go on, but you get the idea.
Here's a brief (and incomplete) summary of some of the tables my old accounting system used:
user: the person using the system; name, password, etc
entity: a company or business; name, government IDs, etc
project: a project that can be billed; name, supplier entity, client entity
timesheet: a timesheet entry: user, project, start time/date, number of hours, description of work