?
Solved

How do I connect the primary key or unique key in the best way?

Posted on 2010-09-04
3
Medium Priority
?
301 Views
Last Modified: 2012-05-10
Hi,

I've searched google etc for an understanding on Primary Keys and Unique Keys but I thought I'd ask here too.

I have a few tables that I want to make sure that ONLY the values in those tables are entered in to a master one.

So, I have:

Country
pk                         - bigint,  indentity auto incerment (1)
countryCode             - nvarchar(3)
countryName             - nvarchar(150)

City
pk                         - bigint,  indentity auto incerment (1)
countryCode             - nvarchar(3)
cityCode                   - nvarchar(3)
cityName             - nvarchar(150)

Store
pk                         - bigint,  indentity auto incerment (1)
countryCode             - nvarchar(3)
cityCode                   - nvarchar(3)
cityName             - nvarchar(150)
storeCode             - nvarchar(3)
storeName             - nvarchar(150)

Now, I have them set up with the PK in each then I use a UNIQUE key between them to only get the values from the other table, so store gets City and City gets Country.

Is this right?

It seems that going down the line a few level that the end table of the unique string could be really long!

Any help or guidance would be much appreciated.

Regards,

Ken
0
Comment
Question by:kenuk110
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
3 Comments
 
LVL 11

Expert Comment

by:JoeNuvo
ID: 33602986
1. You should use countryCode, cityCode, storeCode as PRIMARY KEY by itself without PK field, since you state that it will be unique value. However, you still can keep PK if you want, but just make it as IDENTITY (AKA autonumber)

script example
CREATE TABLE [Country] (
pk bigint IDENTITY (1,1) , -- this line, keep or remove is depend on your need
countryCode nvarchar(3) PRIMARY KEY,
countryName nvarchar(150)
)

2. in order to validate that, City table should enter only valid countryCode, Store table should enter valid cityCode.
This can be done either by your application front end. Or you may setup FOREIGN KEY to perform control over the table

script example

countryCode must be exists for data enter into City table
ALTER TABLE [City]
ADD CONSTRAINT FK_City_Country FOREIGN KEY ( countryCode )
REFERENCES [Country] ( countryCode )
cityCode must be exists for data enter into Store table
ALTER TABLE [Store]
ADD CONSTRAINT FK_Store_City FOREIGN KEY ( cityCode )
REFERENCES [City] ( cityCode )
0
 
LVL 32

Expert Comment

by:Ephraim Wangoya
ID: 33605188
Also in your Store table you do not need a field for cityName since you alredy have the cityCode

You can get it by joining Store to City
select cityName
from city
inner join store on (store.cityCode = city.CityCode)
0
 
LVL 11

Accepted Solution

by:
JoeNuvo earned 1000 total points
ID: 33614628
Addition to ewangoya suggestion

Unless you want to have countryCode and cityName on Store table on purpose.
You can normalize table by remove countryCode and cityName.
and optain it by join the table.

SELECT
... , cityName, countryCode
FROM Store
INNER JOIN City ON Store.cityCode = City.cityCode
or

SELECT
..., cityName,
country.countryCode, country.countryName
FROM Store
INNER JOIN City ON Store.cityCode = City.cityCode
INNER JOIN Country ON City.countyCode = Country.countyCode

0

Featured Post

Tech or Treat!

Submit an article about your scariest tech experience—and the solution—and you’ll be automatically entered to win one of 4 fantastic tech gadgets.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I have written a PowerShell script to "walk" the security structure of each SQL instance to find:         Each Login (Windows or SQL)             * Its Server Roles             * Every database to which the login is mapped             * The associated "Database User" for this …
This is basically a blog post I wrote recently. I've found that SARGability is poorly understood, and since many people don't read blogs, I figured I'd post it here as an article. SARGable is an adjective in SQL that means that an item can be fou…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…
Have you created a query with information for a calendar? ... and then, abra-cadabra, the calendar is done?! I am going to show you how to make that happen. Visualize your data!  ... really see it To use the code to create a calendar from a q…

649 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question