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
Related
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
I'll start of with what I have already:
I've learned at uni how to create databases and now I'm trying to create my own for personal use and possible use for my customer base. The people I work for are on the one hand businesses (Companies) and on the other hand privates (Customers).
I tried to build my database like shown above. I want to be able to add multiple addresses to both my customers and companies. I also have several employees that work for me.
Now, I'm pretty happy with what I have right now but I have the feeling it can be simpler but with the same capabilities (multiple addresses, ...).
Secondly, both Companies and Customers can make orders. Right now I only have a table for Customers to place an order and I'm clueless how I can do the same for Companies.
Should I make a CustomerOrder and CompanyOrder table to achieve this or is there a better solution?
EDIT
I played around a little and actually started over. I tried to take each part like email, phone, fax and put it in its own table. This way, if I update a phone number somewhere and it's used elsewhere, both will be updated.
Below is what I have so far:
Phone, Phone_1 and Phone_2 are the same table, Access just displays it that way. Any suggestions on how I'm doing? ContactType is used if there is CustomerSupport or TechnicalSupport. Type in EntityAddress is to determine if the Address is for a Person or a Company. This way it's expandable for more entities.
Now that I'm Writing this, would it be a good idea to do the same for Phone, Email and Fax like I do with Address?
What I would suggest you is to create a separate table for orders with no link to either customers or to companies. Then you create 2 intermediate tables to link order and company together on the one hand and order and customers together on the other hand.
Fields in the table will look like:
LinkID
CustomerID / CompanyID
OrderID
It avoids having twice the same table (order table).
For the phones, you can do the same thing. This way you can have as many phone numbers as you like linked to one company or customer.
I have a database that seems to be challenging to my knowledge on database design.
I will try to explain and then I will ask the question.
I have a list of companies that have interact with the system and those companies can operate within my country and only my country, all the companies are dedicated to fishing activities. Those companies can have product providers or just fish by themselves. Those providers can operate in any country. The products bought from providers (most of them are frozen fish) can also come from any country and it is not necessarily the provider's country.
Of course I have a country table with the default value set to my country, that table is also referenced by providers and products.
Well, with this design, there is no way to avoid relationships crossing. But my real question are,
is it a good practice to allow this to happen?
If not, how should i redesign it to fix it?
If yes, why everyone tells me to prevent this kind of relations?
Thanks!
Your database design should be OK. Something that need to defined with different country should have to be. There is no something "crossing" logically with it.
The one thing you should avoid in database design is Circular Relation which is A need B, B need C and C need A.
Well, let's analyse the situation:
Those companies can operate within my country and only my country
I'm assuming the companies are represented by the user table; technically they wouldn't need a country, but looking ahead you may want to have companies from other countries.
Those providers can operate in any country.
Okay, so provider definitely needs their own country field.
The products bought from providers (most of them are frozen fish) can also come from any country and it is not necessarily the provider's country.
So product also needs their own country field.
Basically, you will want to represent a product from country X, bought from a provider of country Y and delivered by company from country Z. The model you have designed seems to reflect those relationships correctly.
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 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