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
Related
I´m starting in database schema. I don´t have experience in it.
I am thinking of a platform for customers to have access to the types of products that suppliers offer.
So, I would like to know how to keep the database schema following the tables and their relationships.
The customer will be registered in the system and he will have access to suppliers and their products.
Costumer>>>>>>>>>Product>>>>>>>>>Supplier
I already thank anyone who can help.
greetings
Ed
Based on the data you've given.
You would have a Product table, a product can be sold by one or more supplier. So you would have a Supplier table. Since this is a many to many relationship you would have a cross reference table
Customer's wouldn't be related to Products or suppliers.
Customers generally don't have a direct relationship with Products. Generally, customers create orders, composed of multiple products.
So customers typically have a one to many relationship with an 'Orders' table. The Orders table has a one to many relationship with an OrderItems table. That table might store quantity, color, etc, and has a many to many relationship with the Products table.
Of course, that's just the typical entity relationship. Without more information, it's hard to know if it meets your needs or not.
I am working on a bank application in which a customer can open multiple accounts for different product types like: Insurance, Investment and annuity etc.
Each customer has a profile and we are saving that information in 12 different tables such as : Personal,Contact,Address,Affiliation,Financial,Investment,Asset,Liability,NetWorth and so on.
Now to open each account we have to collect and save same kind of information like for customer profile but we cannot overwrite the customer profile with that as we have to keep track of each accounts information when its submitted to the point when it get opened.
So in terms of solution we think either to have replica of these 12 tables for each account or to save the JSON for each table in one table only which has 12 columns for each of above table and populate UI with that.
Can somebody if have prior experience suggest us how to do this in best way.
I would determine which information will not change between accounts. For example, name, birthday, ssn, etc. These constant fields can form a table called customers. If there are no constant fields, then you can use a placeholder id, which simply helps to associate accounts to the same user.
I would also create a table for Accounts and use the account_id as a foreign key for all your customer information that may change between accounts. Each row in the Accounts table will be owned by a customer from before.
So the relationship between customers and accounts would be one to many, and the relationship between accounts and "account specific customer info" would be one to one.
In this case let me be more specific about the problem
I've got a peoples table(with customer & supplier) and I've got a users table(for users who can login).
Currently I have this DB structure
Customers -> Organisations -> linked through rel_customer_addresses to address table.
(as 1 customer could have delivery_address, invoice address etc.)
Users -> Tenants -> linked through rel_users_addresses to the address table
(as 1 user could have delivery_address, invoice address etc.)
Now I've got in the invoice table customer_key. The problem is when the user himself is the customer and the invoice is from one of his customers. How do I indicate my web app to look up user and not the customer?
Since you're looking at 2 separate entities (customers and users), I would go ahead and use 2 separate tables and have them share a unique identifier (i.e., username, SID).
That way there's no chance of one seeing information from the other without the appropriate permissions.
There are several ways to control this, but the logic is something like this.
If userID exists in table user, do this.
If userID exists in table customer, do this.
If userID exists in table user AND table customer, do this.
That way you can control the situation completely either independently or together. In other words, you could grant special permissions to userID that is found in table customer, or just make it completely separate (similar to say, how facebook makes a separate 'identity' for pages vs the account it's registered to).
Hope that helps!
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.
I am having a brain-cease on a data problem that I am in need of modeling. I will do my best to outline the tables, and relationships
users (basic user information name/etc)
users.id
hospitals (basic information about hospital name/etc)
hospitals.id
pages
pages.id
user_id (page can be affiliated with a user)
hospital_id (page can be affiliated with a hospital)
Here is where the new data begins, and I am having an issue
groups (name of a group of pages)
groups.id
groups_pages (linking table)
group_id
page_id
Now here is the tricky part .. a group can be 'owned' by either a user or hospital, but those pages arent necessarily affiliated with that user/hospital .. In addition, there is another type of entity (company) that can 'own' the group
When displaying the group, I will need to know of what type (user / hospital / company) the group is and be able to get the correct affiliated data (name, address, etc)
Im drawing a blank on how to link groups to its respective owner, knowing that its respective owner can be different.
Party is a generic term for person or organization.
Keep all common fields (phone no, address..) in the Party table.
Person and Hospital should have only specific fields for the sub-type.
If the company has different set of columns from Hospital simply add it as another subtype.
If Hospital and company have same columns, rename the Hospital to more generic Organization
PartyType is the discriminator {P,H}
You'd have to use some form of discriminator. Like adding a column with "owner_type", you could then use either an enum, a vchar, or just an int to represent what type of owner the column represents.
Here is a good tutorial on how to model inheritance in a database while maintaining a reasonable normal form and referential integrity.
Condensed version for you: Create another table, owners, and let it keep a minimal set of attributes (what users and hospitals have in common, maybe a full name, address, and of course an id). Users and hospitals will have their respective id columns that will simultaneously be their primary keys and also foreign keys referencing users.id. Give users the attributes that hospital's don't have and vice versa. Now each hospital is represented by two easily joined rows, one from owners and one from hospitals.
This allows you to reference users.id from groups.owner_id.
(There is also a simpler alternative where you create just one table for users and hospitals and put NULLs to all columns that do not apply to a particular row, but that quickly gets unwieldy.)
HospitalGroups(HospitalID, GroupID)
UserGroups(UserID, GroupID)
CompanyGroups(CompanyID, GroupID)
Groups(GroupID,....)
GroupPages(GroupID, PageID)
Pages(PageID, ...)
Would be the classic way.
The discriminator idea mentioned by #Robert would also work, but you lose referential integrity, so you need more code instead of more tables.