I'm having a issue with with my database organisation, i'm a bit messed up with. Probably something easy who knows. Question is what is better:
- having all data values seperated in the parent tables or
- can I join the 3 values as one single value in parent tables?
My case is:
Table Countries:
Country ID - Name
Table Regions:
Region ID - Name
Table Cities:
City iD - Name
Table Companies:
Company ID - Name - City - Region - Country - etc
OR can I :
Table Countries:
Country ID - Name
Table Regions:
Region ID - Name
Table Cities:
City ID Region Country
and then table cities as a single value in
Table companies:
Company ID - Name - City(city-region-country) - etc
Thanks for your help!
Greets,
Jonathan
I think the second approach is better because there is a big chance of making your data inconsistent with the first one. Also if you wanna change for example the RegionID of NYC, you will have to make it in one place.
Hint - I think the name of a table should not be in plural form, because of many reasons. If you want I can describe them.
So i think you should have the following tables: Country, Region, City and Company and all your FK's should end with ID. For example City should have RegionID and CityID.
Related
I want to build a ER-model for companies.
Some fields for companies are the same, like the name, legal_address and others, but some fields are defined based on the country, where the company is registered.
For example if we take Russia, the company should have fields like inn, ogrn, etc.. (don't matter the names).
If we will take another country - the company will have another set of fields.
I need an advice of how to plan (architect) this.
Any ideas would be great.
At the moment I have this done:
[locations]
id
country
city
lat
lng
zip_code
[companies]
id
location_id
name
director
legal_address
actual_address
[company_russia]
id
company_id
inn
kpp
ogrn
stat_codes
reg_number_fss
reg_number_pfr
But I think there will be problems joining the tables and that each other country requires a separate table - is not a good approach.
I'm currently designing a database for a project I have in college and I would really appreciate some feedback. Basically, the idea of the project is to create a food plants, food inventory database. I have created a schema for the database but I'm not sure if the products table abides by 3NF.
So my products table contains p_id( the primary key), the name of the product, what type is the product (eg pizza or dessert), the country it comes from, the region in that country and who the product is suitable for (eg vegan).
So basically when I break it down, I feel that Region is dependant on Country and type is dependant on the name? Would I be right in assuming this? I could then split the table into 3 separate tables. 1 which would contain p_id, name, Country and another one which would contain Country, Region and a third one which would contain name and type. Would this then be a fully normalised database up to 4NF?
Here is a my schema:
I have two tables States and Cities.
In teststates table: there are data regarding states of different countries
The code column has id for states associated with it
In Cities table:
there is region column which has same id as of code column in teststates table.
Requirement:
I want the Code in mysql to fetch id from the teststates table column and replace it into region column in testcities table as I want only two columns which are city name and region in testcities table. Please help me!
select a.name,b.region from teststates a,testcities b where a.country = b.country
This will return City Name and Region Name columns joining on Country name from both tables.
I have a strange problem. I got some data for cities, regions and countries in CSV format and imported them into MySQL tables.
I have 3 tables and their fields
1. City : id, name, country_code, region_number
2. Region : region_number, country_code, name
3. Country : country_code, name
Now things get a little complicated, as I added an auto-generated id column to the region table, so the region x for country y would be unique.
The thing is: Now i am trying to update city field region_number to hold this unique value (the new id column in region) so I can have relations city->region.
The relation region->country or country->region is OK.
Is it possible to write an update query that would update city region_code (or fill some new column, eg. region_id) with correct values?
If not an query, what could I use to get the correct values into the cities table?
I have arround 3 million records!
If I understant correctly, I think you are looking for something like this:
UPDATE
City inner join Region
on City.country_code = Region.country_code
and City.region_number = Region.region_number
SET
City.new_column = Region.id
However, since there's a relation already between City and Region, I am not sure this is the right thing to do, since it will make the table not normalized.
Now i am trying to update city field region_number to not hold this unique value
The only way you can do this is if the region_number uniquely identifies each region - and if that's already the case then you are wasting your time by creating redundant references. Although frankly, if these really are your table structures, there's no reason for using surrogate keys. And if there's no reason for using surrogate keys then the region and country table are redundant.
My question is how to model transactions for different types of products.
So there is a Transactions table:
TransactionId(pk)
Amount
Method
AuthorisedBy(fk)
And there are different tables for different types of products.
Books table:
BookId(pk)
Name
Description
Price
And a Pens table:
PenId(pk)
Color
Description
Price
And a table for pencil sharpening services:
SharpenId(pk)
Description
Price
Now my question is linking the transactions with the particular id's of the different items.
One method was to have in the transaction table:
TransactionId(pk)
Amount
Method
AuthorisedBy
ProductType
ProductTypeId(fk)
Where product type would refer to the title of the table, eg Books and the product id would refer to the BookId in that case.
OR another method would be to have a linking table of 'products' that refer to each different id of the other tables, so the Transaction table would look like this:
TransactionId(pk)
Amount
Method
AuthorisedBy
ProductID(fk)
and the products table would look like this:
ProductId(pk)
PoductType
ProductTypeId(fk)
But then this is a table that is exactly the same as the transactions table. So my question is how do I efficiently link the different product type tables to the transactions?
Please note I am not modelling a school pencil sharpening service, they're just examples :P
First of all i dont like the DB model. You need only one table for product definition that can hold columns that describes every product:
(table)Products: ID - PK, Name, Description, Color, Price, ProductTypeID - FK
You need additional table that explain the type of the product, it's category let say:
(table)ProductTypes: ProductTypeID - PK, ProductTypeName
And for registering transactions you will need only one table:
(table)Transactions: TransactionID, ProductID - FK, Amount, Method, AuthorizedBy
I think this schema will be OK for you to resolve your issue.
Happy coding.