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.
Related
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.
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 tables to hold information about Lakes, Counties, and States. I also have a table called LakeLocation that is simple a pair of foreign keys of a LakeID and CountyID, so I can know where they are. And each county has a StateName inside it.
A high-level view of it all is something like this:
Lake = {id,name,...}
County = {id, name, StateName ....}
State = {name, ...}
LakeLocation = {LakeID, CountyID}
I am trying to find out which states have lakes that are in more than one state. An example is Lake Tahoe which crosses four county lines and two state lines. I know that I will need a recursive query, but I only understand those for simple one table child/parent type relationships. Not this.
How can I design a query that does what I need? Thanks
You only need a group by to know what are the lakes
SELECT LakeID
FROM LakeLocation
GROUP BY LakeID
HAVING COUNT(CountyID) > 1
Then if you want lake names
SELECT *
FROM Lake
WHERE LakeID IN (<previous query>)
I need to create database which will contain the following entities in country:
Regions
Municipalities
Now comes the hard part for me:
Municipality can also be city, where city can (but not always) have its own municipalities.
Municipality can have several cities.
Municipality in both cases contains several settlements
I wanted to create several tables, for example:
regions (region_id, region_name)
municipalities (municipality_id, municipality_name, region_id).
cities (city_id, city_name, region_id)
city_municipalities (city_municipality_id, city_municipality_name, city_id)
settlements (settlement_id, settlement_name, municipality_id, city_municipality_id)
i think that here i make problem. There would be a lot of NULLs for municipality_id or city_municipality_id, since i cant have both field filled.
But right now it comes to my mind to have two tables organized like this:
geo_entity(geo_id, geo_name, geo_type_id, parent)
geo_entities_type (geo_type_id, geo_type_name)
this table will contain definitions of what geo_entity entry is, like:
1 Region
2 Municipality
3 City
4 City Municipality
5 Settlement
What should i stick to? Do you have a better approach and which one?
I am trying to understand this concept. For example: I have two tables City and Country.
Country
-------
id
abbreviation
name
City
-----
id
name
Country (name or id, or both? - This is the question)
To reference and keep a particular city in sync with the country it belongs to I guess this will be reference to country.id as a FK. This means an example of the city table will be: (200, New York, 19) - where 19 = USA in country table. But this doesn't help a person viewing the table because he wont know what 19 is without looking up in country table what 19 is.
So I want to add the country name also to city table so it reads: (200, New York, USA). I don't need the 19 to display because 19 is of no use to the reader but is only used in back to connect the tables.
So what should my tables colunms / FK look like to i can store in city table rows like this (200, New York, USA), yet ensure New york will always reference to USA in the USA lookup and keep the 19 which is the primary key for USA out of the city table so the tables look clean and easy to understand? And I assume if these are referenced, tomorrow if i update USA to be 20, it will update in the city table on its own, and same way if I rename USA to US it will update on city table on its own?
My DB is in MySQL
Why not use ISO 3166 country codes (2 character or 3 character) as the country ID? This leaves you with recognizable codes in the city table; you can map to the full name in the country table.
As for viewing the data, use a VIEW to create a good looking table:
CREATE VIEW CityInfo(CityID, CityName, CountryID, CountryName) AS
SELECT ci.id, ci.name, ci.country, co.name
FROM City AS ci JOIN Country AS co ON ci.Country = co.id;
You don't ... if you need to have "usable" tables in the DB, so someone can easily view something useful with select * etc. (or to make programing the SQL by hand easier). Then you create the tables as above, in normal form, and then create a VIEW which combines the tables.
Tables aren't supposed to be viewed by people: some application should be accessing the tables to present data to people in a way they can parse it. The reason you want to have country.id as a FK in your table is so that you don't have a million rows whose country name is "USA", because then all kinds of problems can occur, like what happens when you mistype and "US A" lands in one of the fields? Or what if you want to change what the user sees from "USA" to "United States"?
The right way to handle it is to use the country.id as you initially suggest, and then use a JOIN statement to present the data, like this:
SELECT city.name, country.name
FROM city JOIN country ON country.id = city.country
My syntax could be off, but that's in essence what you want.