I have an application which handles the creation of different shop entities.
The process:
1. User registers to the website
2. User creates a shop (with various attributes)
What I have so far for database tables is:
[USER]
user_id
[USER_TO_SHOP]
user_id
shop_id
[SHOP]
shop_id
The above design covers the need for 1 user to have many shop entities under their account.
What I want to achieve now, is to have shop entities which are standalone but also have shop entities which are a part of group of shops
Chain of Shops example:
McDonalds Address X Chicago
McDonalds Address X New York
McDonalds Address X Boston
How should I proceed with my database design in order to support chain of shops but also standalone ones? Best practices are really appreciated!
*by standalone I mean a shop entity that does not belong to a chain
Off the top of my head I'd have a locations table and rename shop to company so single companies go into that table but can have multiple locations. Then users are associated with a company location.
There are many ways to achieve what you want, so, answers will be subjective since we don't really have the whole picture.
From what you're saying, a shop can belong to between 0 and 1 chains? If so, I would simply add one extra table and add a foreign key to the shop table:
[CHAIN]
chain_id
chain_name
[SHOP]
shop_id
chain_id
Well, for chains, you could have something like this, just like you have for users:
[CHAIN]
chain_id
[CHAIN_TO_SHOP]
chain_id
shop_id
Not sure what you mean by a standalone shop though - if you mean a shop that isn't owned by a user or a chain, could be something like this:
[STANDALONE_SHOP]
shop_id
But I would question the need for such a table, since a standalone shop could be assumed by an absence of an entry in CHAIN_TO_SHOP or USER_TO_SHOP
Related
Let's say my company is producing medical products, these products are used in many different lab testing instruments. The business logic hierarchy goes like this:
A lab has multiple locations (Up to thousands)
A location has multiple departments (Chemistry, Hematology, 3-5 per location)
A department has multiple instruments (No more than 10-20 instruments per location)
An instrument has many products.(No more than 1-5 product types per instrument)
The table structure currently mirrors the business logic, like displayed on the left. I suggested we make a small change, displayed on the right.
What are some pros and cons of each approach? I feel like the left-hand side approach might be a bit slower due to chaining so many Joins in a row.
The biggest "con" I see to the approach on the right-hand side is that you lose the association between Department and Location. For the relationships that you described atop your post, the structure on the left is correct from a design perspective.
HOWEVER...
The design that you have means that the Mass Spectrometer at your San Antonio facility will have a different ID than the one at your Denver facility. Is that intended?
------------------ revision after discussion in comments ------------------
You've described a couple of many-to-many relationships - a location will have multiple instruments and multiple locations can have the same instrument (e.g. Mass Spectrometer). To support that, you'll need cross-reference tables. Here's an initial sketch. My standard is to call the table's primary key "ID", and any field called "[table-name]_ID" is a foreign key to the corresponding table:
Lab
ID
Name
Location
ID
Lab_ID
Street_Address
City
etc.
Department
ID
Name
Location_Department -- this lists the departments at a given location
ID
Department_ID
Location_ID
Instrument -- Scale, Oscilloscope, Mass Spectrometer, etc.
ID
Name
Description
Location_Department_Instrument -- inventory at a given location
Location_Department_ID
Instrument_ID
Instrument_Serial_Number
Let me know if this makes sense.
I am working on a site which provides coupons for online shopping sites.
It provides discount coupons for shopping sites in India.
But now the client wants to provide coupons for USA stores also.
But offers available for Indian users are not useful for the USA users and vice versa.
Therefore there will be two versions of the site. One is for the Indian users and other is for the USA users.
But if a user from India searches for an offer which is not available in India but is available in the USA. Then it should appear in search results.
Now I am thinking of creating a new database for the USA users with exact same schema as that of the database for current users(Indian users).
But I would like to get advice from an expert.
In the long run you might want to add more countries so I would do it by adding a country table kind of thing and something like offer_valid for offerid country id which would make a single offer valid for one country or more.
Creating multiple databases would make the maintenance hectic.
Creating a separate database or a separate table (by adding _usa to table name) for that matter does not make sense.. because the same can be achieved by creating a mapping table which maps offers/coupons to the country/countries for which it is valid and is more scalable as well.
Here is what I suggest:
countries: id, name
coupons: id, name, discount
coupon_country_mapping: id, country_id, coupon_id, is_active
Hi I am new to development. I am wondering how the database would be structured?
I will have a table for all the store with their addresses, hours, lat/lng, emails. But what about the products? Each store will have multiple products and the user will be able to enter the product on a search input, the stores will be listed and the googlemap will mark all of them.
My question is, should the products be on a seperate table joined with the stores table? If so, should each product be on it's own column like product1, product2, etc? They will need to be connected with the stores.
I suggest you make 3 tables. Product, Shop and the third (Product_Shop) to connect these two tables since you have a m:n (many to many) relationship.
A product can be placed into multiple shops and a shop can contain multiple products. Example: (a shop called tesco can contain products like: milk, juice.., and milk can be located in a shop called tesco, sainsbury, Mark and spencer ect.)
Because of that you need the "connection" table. If you want to learn more, there are loads of explanations on line. Just google: "database relationships"
Here is an example of that, if you want to add more attributes (columns), then do so.
Basic tables and connections:
To connect your database with google maps I suggest to read the following (always refer to the documentation first):
URL:https://developers.google.com/maps/articles/phpsqlajax_v3
New to database design and admittedly over my head. Trying to create a small database that will allow me to find state highway construction project information along any given road. Relationships include:
One contract number to one project; One county to many projects; One road to many projects; One road to many counties and one county to many roads; One manager to many projects; One contractor to many projects; One contact list (phone, email) to one manager; One date each (bid, start, complete) to many projects.
Would be a small database, maybe 500 records total. There are only 6 counties. Right now I've broken roads down into 6 separate "roads by county" tables so while the route number may be the same in different counties each record will be unique because it's in a separate county table. Is this OK or is it better to keep one roads table and assign county values there? I created other tables listing the counties, contracts, contractors, managers, dates and project description. Just don't know what to do with them.
My purpose is to be able to search, mostly by road number and keyword, to find what projects are on what road at any given time. I'd also like to update this info via forms. The data will change frequently and it's just a little too unruly for a spreadsheet. I simply can't wrap my head around how to setup and relate the tables and individual records. Any thoughts would be phenomenally appreciated.
I imagine a database with a simple structure.
The relations many-to-many normally should and can be avoided.
Access doesn't have a direct implementation of this relations. You need to create a cross table between the two main tables.
Anyway I created a database for projects more complex than this so I tried to accomplish your request.
The "core" table is tblProjects that refers for details to other tables.
Since projects are related to roads, I use road as the main item and a road can have a list of counties. If you want to know how many projects are in a county it can be simply done with a query looking for all the roads that have that County_ID.
If you want to look up for project for one road, simply find the road_ID (e.g. using a combo-box to select it) and you can filter (query) the tblProjects by Road_ID.
tblManagers
*IDManager
LastName
FirstName
eMail
Phone
Mobile
tblContractors
*IDContractor
ContractorName
Reference
tblCounties
*IDCounty
CountyName
Road_ID
tblRoads
*IDRoad
RoadNum
RoadName
tblProjects
*IDProject
ContractNum
ProjectName
StartDate
EndDate
BidDate
Contractor_ID
Road_ID
Manager_ID
The fields with * are the Key Fields. They are in relations with the _ID corresponding fields (check referential integrity and cascade deletion when you create the relation).
Let me know
I am building a database on Access that, among other things, tracks who has referred patients to our office (I work in an optometrist's office which does a specialized kind of therapy).
I don't have much experience creating relational databases, and I am wondering if I'm heading the right direction. Before posting here, I've asked 5 of my computer programmer friends for help, but suddenly every is busy... So here goes.
1 patient can have Many referrals
my son's teacher and my coworker referred me here (2 referring
sources)
my doctor told me about you, and then I saw your website (2 referring
sources)
1 referral can consist of:
an individual (Dr Blah-Blah, or My Friend Jane Doe)
an organization (Doctors Group)
an individual that is part of an organization (Dr. So-and-So from Doctors
Group)
a media source (website, pamphlet, commercial, tv show, etc)
Often it's not possible to determine which individual at an organization referred the patient (because patients can't remember), so only the organization is recorded. But sometimes it is possible, so the individual and the organization are recorded. And sometimes individuals are not part of any organization.
This is the partial design that I came up with: http://postimg.org/image/uipaq7rrl/
Patients Table
Referring Media Table
stores details of media sources
Referring Organization Table
stores the names/details of organizations
Referring Individuals Table
stores names/details of individuals
uses Ref Org ID as a foreign key, in case individuals are members of an organization
Referrals Table
uses the Patient ID as a foreign key to link the referrals to the patients
How should I link the Referrals Table to the Ref Org, Ref Indv, and Ref Media tables?
I came up with something like this: http://postimg.org/image/qtpoiflmv/
But that seems redundant and leaves a lot of blank spaces, depending on the type of referral: http://postimg.org/image/oepj99ohz/
What should I do? What is a good way to build relationships between these tables?
without even thinking or getting involved, if you see spaces like that, looks like you need a table with referral types