I have a large table with all of the state and county information in America in one place.
table structure is
fullCode countyName stateName stateCode
1 01001 nowhere AL 01
2 01003 somewhere AL 01
3 02100 other AK 02
The state code is always identified by the first two numbers in the fullCode column. These are unique to each state so no state will have more than one set of preceding two numbers. The last three numbers on the countyCode.
I used the query below to create a table with all of the states
select distinct stateName, statecode
into tblStates
from tblCounties
I'm curious how one could create a table for each state's counties in one fell swoop (if possible). Something like
select distinct fullCode, countyName
into tblAlabamaCounties
from tblCounties
where stateName='AL'
but for every state. Then of course I'd have to deal with all the PK/FK issues. Just wondering the methods that might be employed to do something like this.
EDIT: if this is a design error, how else can I associate the names of a county that are in a particular state? I could leave everything in one big table, but that seems like poor design, thoughts?
Here would be a better design you might consider:
State Table:
STATE_ID
STATE_ABBREV
STATE_NAME
County Table:
COUNTY_ID
STATE_ID
COUNTY_NAME
Sample Data:
STATE_ID STATE_ABBREV STATE_NAME
01 AL Alabama
02 AK Alaska
COUNTY_ID STATE_ID COUNTY_NAME
001 01 Nowhere
003 01 Somewhere
100 02 Other
Your Primary Key for the state table would be the STATE_ID
Your Primary Key for the county table would be COUNTY_ID ---AND---- STATE_ID (COMBINED)
With this structure, you've got just 2 tables, with which you can easily reproduce your original "large" table, as well as the "full code" field. Additionally, updating, querying, creating procs, functions, etc. is going to be a lot easier down the road based on this (much simpler / more normal) structure.
FWIW
If you use Oracle, you could create a PL-SQL procedure where you create first of all the different tables, and then you only have to populate the data into the new tables recently create.
IF you use PL SQL procedure you could do it.
On the other hand you can create the different tables, and create a triggers before insert, and you will insert the data in the specific table before insert in your master table.
Sorry for my English I hope you can understand all and help you.
Related
i have a table like:
name
location
Emma
Athens
Nick
Berlin
Emma
Athens-Greece
Nick
Berlin, Germany
Emma
233 Street, Athena
Nick
Berlin's
at first, i want to change all values like '%Athen%' to 'Athens' and the same for Berlin
my problem is that my table is full of values like that and it's big , so i wonder if there is a way to do it faster without writing every city-case, such as using functions like substring or creating a function with general forms of my data.
I mean that i don't want something like:
update Person set city='Athens' where city like '%Athen%'
i have to have one name for the same city because, about the above example, it's the same emma who lives in athens and the same nick who lives in berlin, so i have to normalize my table to see only one time each person from each city.
I don't believe there is a simple solution that means you don't have to check every value. The way I would do it would be:
Create a distinct list of every unique location value
Put this distinct list in column 1 of a 2 column "lookup" table
In the second column put the "clean" version of the value in column 1
Write a query that will update the values in your source table based on the values in your lookup table
Having the data in a table, rather in some form of complex SQL CASE statement, makes the information much easier to maintain and the SQL to update your source table much simper
I have country, region, county, town data and I'm currently deciding between 2 schema designs (if there's a better one, do tell).
I first thought
Country
Id
Name
Region
Id
CountryId
Name
County
Id
RegionId
Name
Town
Id
CountyId
Name
Does the job however to get all towns in a country you have to 3 inner joins to do the filtering. I guess this could be ok but potentially expensive?
The other design was:
Country
Id
Name
Region
Id
Name
County
Id
Name
Town
Id
CountryId
RegionId
CountyId
Name
This way all hierarchical data so to speak is at the bottom and you can go back up however if you want all regions in a country you're a bit screwed which makes we wonder whether the first design is best.
What do you think is the best schema design?
The best database design depends on how the data is being used.
If this is pretty static data that will all be updated at one time and external references are all to towns, then I would probably go for a denormalized dimension. That is, store the information all in one row:
Town Id
Town name
County name
Region name
Country name
Under the above scenario, the ids for county, region, and country are not necessary (by assumption).
If the data is being provided as separate tables with separate ids, and these tables can be updated independently or row-by-row, then a separate table for each makes sense. Putting all the ids into the towns table may or may not be a good idea. You will have to verify and maintain the hierarchies when data is inserted and updated.
If ids for each level are necessary for your, then you should have appropriate table structure for declaring foreign key constraints. But, this can get complicated. Will an external entity have a "geography" attribute that can be at any level? Will an external always know what level it is going to refer to as?
In other words, you need to know how the data is going to be used in order to define an appropriate data model.
Hi I just want to sort out these fields to a table. But I'm having trouble.
I have details of cities.
These are main city detail examples.
CityName CityID
Colombo 001
Kandy 002
Kandy is Directly connected to these cities
CityName CityID DistancefromKandy
Katugastota 006 1km
Peadeniya 008 2km
I want to store distance between every city. As an example Katugastota to Peradeniya, Colombo to Katugastota, Colombo to Kandy and Kandy To Peradeniya too.
And for a singe city I want to store what are the directly connected cities and the distance to those cities.
How to sort this data to tables..?Any ideas.. I have given the table structure I tried but I cant add the distance between each city in to that and the directly connected cities and distance to directly connected cities in this..
Appreciate any help in this..
I just don't need the sql, if someone can suggest a better table design that would be a great help.
Like #EvilEpidemic suggested above, my first choice would be to store coordinates (latitude & longitude) for each city and calculate the distances between them.
That said, if you need to store your pre-calculated distances for specific pairs of cities, then you may want to try the following:
Add a table that includes two (2) CityID columns (for example, SourceCityId and DestinationCityId) as well as a NOT NULL distance column (of a numeric data type).
For example, in SQL Server you might have a table like (this oversimplified example assumes you store distances as int kilometers, but feel free to change the data type as needed):
CREATE TABLE Distances (
[SourceCityId] NOT NULL int,
[DestinationCityId] NOT NULL int,
[DistanceInKilometers] NOT NULL int,
CONSTRAINT [PK_Distances] PRIMARY KEY CLUSTERED (
[SourceCityId] ASC,
[DestinationCityId] ASC
)
)
I would like to create a field in my sql query based on the data in another field. For example:
First Name Last Name Hometown State (created column based on Hometown)
Phil Smith Brooklyn NY
Bill Jones Manhattan NY
Abraham Phillips Cleveland OH
Michael Davis Cincinnati OH
William Brett Queens NY
The "State" column could come from a look-up table or in an if / else statement. I'm not sure how to do this, so I would appreciate any help.
This is one "solution", there are many more.
You could create one table called "Person" consisting of FirstName, LastName and Hometown (I presume you may have that table already) and a lookup table called "CityToState" with City and State.
Fill the lookup table with appropriate data (it'll be quite large, I'm sure) and issue the query
select FirstName, LastName, Hometown, State
from Person left join CityToState on Hometown=City;
That should give you the correct data, with NULL returned for the state if the city does not exist in the lookup table.
Basically what this does is to get all data from Person and join it, row by row with the row in CityToState where HomeTown is the same as City. The "left" part means that it should return the row from the left table (Person) even if there is no matching row in CityToState.
look up computed column for the database you are using (which you do not state in the question). Here is info on SQL Server's Computed Columns.
However, I think you should use a different design. If you are looking up the state based on the hometown, a foreign key is enough, no need to duplicate the data.
Suppose I have the following:
Table region_city
id name parent_id
==============================
1 North null
2 South null
3 Manchester 1
4 London 2
In my user table I store the ID of the City that the user is in.
Now in my search form I need to be able to perform a top-level search, i.e. find all Users that belong to a given region (North or South).
Will it make life easier if I included a region_id field in my user table? Or is that going against the normalisation concept?
It does denormalize the table structures and it could introduce data update anomalies. Consider: the user moves from Manchester to London and the city_id changes. The region_id could still point to the North.
The region_id only depends on the city therefore it does not belong in the user table. Since it can be derived from the city.
If the design absolutely calls for only two levels (region and city) and you are willing to forgo the possible addition of other levels in the future (not a decision I would be inclined to make, but you know your data better than I do) then do not include the regionID in your user table; that would denormalize your database. Instead, you have several choices for representing the data (including two related tables, region and city) and you would perform your search by JOINing the city table to the user table or using an IN clause in your search.