I am having trouble thinking of how I should build my simple database, its been about 3 years since I have done any sql dev which was back at uni so I have had habit of a brain fade.
I have two tables
business
customer
A customer can belong to many businesses and a business can have many customers.. so far I have created this as a database..
The Business table looks like this
- id
- name
- address
Customer table:
- id
- name
My question is how do I link these two together, how do i keep track of which customers are with which businesses so if a customer joins a business do I need a new table that is like business id and customer id??? I'm just a bit lost, hopefully you guys get what I am asking.
any help would be greatly appreciated.
if you want to link just two tables. the link to this question will be a fit for you: link two database tables
I would go with the party model, with a relationship table. This lets you have individual or organization customers (or busineses) and multiple relationships between them:
PARTY
id
type: {individual, organization}
name
RELATIONSHIP
fromParty references PARTY
relationshipType: {customerOf, organizationalContactOf, leadOf, staffOf, vendorOf}
toParty references PARTY
Related
This question already has answers here:
Meaning of "n:m" and "1:n" in database design
(9 answers)
Closed 3 years ago.
I have started a new job recently as .Net Developer, in that for the projects that I am working on requires strong understanding of relationships like
1-N, 1-1 and N-N. I have completely understood 1-1 relationship with real life example like In a Tablets and Billing table if Billing table has TabletId as a foreign key then there is 1-1 relationship between them, but talking about 1-N and N-N relationship regarding same tables how the real life example can be put forward. I have not completely understood.
Tablet
TabletId
Name
description
Maker
ExpiryDate
Billing
BillingId
TabletId F.K
TDate
so from above table structure it is clear that one bill can have one tablet only. but if i want one bill can have multiple tablets then how will i achieve that.
Please give me example of Tablets and Billing table for 1-N and N-N relationships
When talking about relationships in a database, one could be more precise by stating the minimum and maximum links. The relations we usually see in a database are:
1:1 implemented as {1}:{0,1} Example: a user has or doesn't have one address. So, each user has 0 to 1 addresses; an address belongs to one user.
1:n implemented as {1}:{1,n} Example: a user has one or more or no phone numbers. So, each user has 0 to n phone numbers; a phone number belongs to one user.
m:n implemented as {0,m}:{0,n} Example: a product in one or more or no shops; a shop sells one or more or no products.
And here is how we omplement these relations:
The address table has a user ID and it's the table's primary key.
The phone table has a user ID.
There is a bridge table linking product and shop consisting of these two columns: product ID and shop ID.
Of the three relations the first (1:1) is rare. Usually we would rather store the values in a single table. But in the address example we could use it to easily guarantee that a user either has a full address with both street and city and country given or none at all.
The 1:n and m:n relations are both frequent in databases.
So I’m attempting to teach myself databases and SQL, and I’m trying to play around with making a database in management studio, and I have a question regarding recursive relationships in a table. Say I have a table called ‘Customers’ and in that table I have an int called Customer_ID as the primary key that is also an identity incrementing by 1, an nchar(125) called ‘Customer_Name’, and another int called Customer_Parent_ID (I don’t know whether I should make this an identity or not). How do I go about forming the relationships that there are customers, and I want to track that some of those customers may be parents of other customers (Think of companies, for example say both Microsoft and LinkedIn are customers, but Microsoft is also LinkedIn’s parent company and I want to show that relationship). I attached a picture of what I THINK it should look like… but again, total newbie here and any recommendations would be much appreciated.
Thank you so much!
EDIT: Added SQL Code and removed accidental mysql tag.
I think your question is somehow similar to this one, and the simple answer is you set a foreign key on Customer_Parent_ID column and refers to the Customer_ID column, so any id number that appears in the Customer_Parent_ID must also present in the Customer_ID column.
I am using access 2007. I made a database called holiday which has 3 tables namely:
client - this has all the client information
flight - this stores flight information
cruise - this stores cruiser information
what I'm thinking of doing, is to make a relationship between these three tables. I just thought myself "relationships" from google and from what I understand is that I should use a one-to-many relationship.
I did that each table has a column called customerID where the client table has it as a primary key and the others as foreign-key. What I want to know is how do I link up the tables so that when I enter information onto the client table both flight and cruise should open as subselection because currently only one is opening and I don't know how to enter the other?
There's 2 ways to create a relationship between tables.
One is permanently with the Relationships Window (under Database Tools in Access 2010). Drag from a field in one table to a field in an other table. Then double click on the line (join) to edit the join type.
The other is to do this temporarily in A Query Builder window. Then you create the join the same way as above. This join is only set in this query only, or anything else based on this query.
OK, now that you them joined, what are your plans. One way is to create a form for editing the customer info, along with two sub-forms for editing the flight & cruise info.
Good luck
I have a table of People, and a table of Service Tickets. Service Tickets refer to 1+ People, and over time People are likely to be associated with multiple Tickets. What is the best way to represent this relationship in a SQL database?
It seems like my two options are to create 'enough' columns to contain all the person id's i should need, or a single huge string column that is processed CSV style after being fetched from the database. Both of these options have a maximum capacity, which seems like a bad design, and the second design means we can't join using the person id's.
A little background - I'm implementing a fairly small database as part of the backend for a class project. I've never really worked with SQL and what I know is self taught.
I feel like this is has to be a duplicate question, but I'm unable to find anything similar.
No, if this si a MANY to MANY relation ship, creat the table accordingly.
Create a table, something like
PeopleServiceLink:
PersonID,
ServieTicketID,
PRIMARY KEY (PersonID, ServieTicketID)
Have a read hear at Understanding SQL: Many to Many Relationships
For many-to-many relationship generally create three tables: Tickets(id, ...), People(id,...) and join table like TicketsPeopleJoin(ticketId, peopleId)
Create a separate tickets_people table which has person_id & ticket_id columns.
I have a doubt regarding a database design, suppose a finance/stock software
in the software, the user will be able to create orders,
those orders may contain company products or third-party products
typical product table:
PRIMARY KEY INT productId
KEY INT productcatId
KEY INT supplierId
VARCHAR(20) name
TEXT description
...
but i also need some more details in the company products like:
INT instock
DATETIME laststockupdate
...
The question is, how should i store the data?
I'm thinking in 2 options:
1 -
Have both company and third-party, products in a single table,
some columns will not be used by third-party products
identify the company products are identified by a supplier id
2 -
Have the company products and third-party in separated tables
3 - [new, thanks RibaldEddie]
Have a single product table,
company products have additional info in a separated table
Thanks in advance!
You didn't mention anything about needing to store separate bits of Vendor information, just that a type of product has extra information. So, you could have one products table and an InHouseProductDetails table that has a productId foreign key back to the products table that stores the company specific information. Then when you run your queries you can join the products table to the details table.
The benefit is that you don't have to have NULLable columns in the products table, so your data is safer from corruption and you don't have to store the products themselves in two separate tables.
Oooo go with 3! 3 is the best!
To be honest, I think the choice of #1 or #2 are completely dependent upon some other factors (I can only thing of 2 at the moment):
How much data is expected (affecting speed of queries)
Is scalability going to be a concern anywhere in the near future (I'd guess within 5 years)
If you did go with a single table for all inventory, then later decided to split them, you can. You suggested a supplier identifier of some sort. List suppliers in a table (your company included) with keys to your inventory. Then it really won't matter.
As far as UNION goes, it's been a while since I've written raw Sql - so I'm not sure if UNION is the correct syntax. However, I do know that you can pull data from multiple tables. Actually just found this: Retrieving Data from Multiple Tables with Sql Joins
I agree with RibaldEddie. Just one thing to add: put a unique constraint on that foreign key in your InHouseProductDetails table. That'll enforce that it's a one-to-one relationship between the two tables, so you don't accidently end up with two InHouseProductDetails records for one product (maybe from some dataload gone awry or something)
Constraints are like defensive driving; they help prevent the unexpected...
I would advice on using point #1. What happens when another supplier comes along? It's also more easy to extend on one product table/produst class.
Take into account the testing of your application also. Having all data in one table raises the possible requirement of testing both the 3rd Party & Company elements of your app for any change to either.
If you're happy that your Unit test would cover this off its not so much of a worry... if you're relying on a human tester then it becomes more of an issue when sizing the impact of changes.
Personally I'd go for the one products table with common details and separate tables for the 3rd party & Company specifics.
one table for products with a foreign key to the Vendor table; include your own company in the Vendor table
the Stock table can then be used to store information about stock levels for any product, not just yours
Note that you need the Stock table anyway, this just make the DB model more company-agnostic - so if you ever need to store stock level information about third-party products, there's no DB change required