Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2005
»
SQL Server 2005 General Discussion
»
confusion in setting up superkey
confusion in setting up superkey
Rate Topic
Display Mode
Topic Options
Author
Message
deba_20032004
deba_20032004
Posted Monday, October 15, 2012 7:08 AM
Valued Member
Group: General Forum Members
Last Login: Tuesday, May 14, 2013 1:33 AM
Points: 50,
Visits: 219
Dear Sir,
I am in great trouble, my problem is I have a vendor Table
which consist of some fields. I explaining the structure below
Table<Vendor>
--------------
fields name
-----------
PKID int
VENDORID int
VENDORNAME varchar (50)
ADDRESS varchar(50)
CITY varchar(15)
I have set Primary key on PKID (cluster index)
I have set non cluster index on (VENDORID,VENDORNAME/ADDRESS) FIELDS
now I want to set superkey on (VENDORID+ADDRESS+CITY) which identify unique record.
is it right structure for creating index
please give me suggestion
thanks in advance
Debasis
Post #1372714
foxxo
foxxo
Posted Monday, October 15, 2012 10:20 AM
Say Hey Kid
Group: General Forum Members
Last Login: Today @ 1:08 AM
Points: 707,
Visits: 1,048
You can create a unique non clustered index on (VENDORID+ADDRESS+CITY) since your primary key is already specified. You can specify a unique key constraint when creating the table also.
Post #1372808
ChrisM@home
ChrisM@home
Posted Monday, October 15, 2012 10:23 AM
SSC Eights!
Group: General Forum Members
Last Login: Yesterday @ 11:25 PM
Points: 921,
Visits: 3,743
deba_20032004 (10/15/2012)
Dear Sir,
I am in great trouble, my problem is I have a vendor Table
which consist of some fields. I explaining the structure below
Table<Vendor>
--------------
fields name
-----------
PKID int
VENDORID int
VENDORNAME varchar (50)
ADDRESS varchar(50)
CITY varchar(15)
I have set Primary key on PKID (cluster index)
I have set non cluster index on (VENDORID,VENDORNAME/ADDRESS) FIELDS
now I want to set superkey on (VENDORID+ADDRESS+CITY) which identify unique record.
is it right structure for creating index
please give me suggestion
thanks in advance
Debasis
Why does your vendor table have both a PKID and a VendorID?
Low-hanging fruit picker and defender of the moggies
For better assistance in answering your questions, please read
this
.
Understanding and using APPLY, (I)
and
(II)
Paul White
Hidden RBAR: Triangular Joins
/
The "Numbers" or "Tally" Table: What it is and how it replaces a loop
Jeff Moden
Post #1372809
dwain.c
dwain.c
Posted Monday, October 15, 2012 7:05 PM
SSCrazy
Group: General Forum Members
Last Login: Today @ 12:39 AM
Points: 2,345,
Visits: 3,189
ChrisM@home (10/15/2012)
deba_20032004 (10/15/2012)
Dear Sir,
I am in great trouble, my problem is I have a vendor Table
which consist of some fields. I explaining the structure below
Table<Vendor>
--------------
fields name
-----------
PKID int
VENDORID int
VENDORNAME varchar (50)
ADDRESS varchar(50)
CITY varchar(15)
I have set Primary key on PKID (cluster index)
I have set non cluster index on (VENDORID,VENDORNAME/ADDRESS) FIELDS
now I want to set superkey on (VENDORID+ADDRESS+CITY) which identify unique record.
is it right structure for creating index
please give me suggestion
thanks in advance
Debasis
Why does your vendor table have both a PKID and a VendorID?
Maybe he wants to be able to change the VendorID at some future time?
No loops! No CURSORs! No RBAR! Hoo-uh!
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Are you too recursively challenged?
Splitting strings based on patterns can be fast!
Post #1373006
Eugene Elutin
Eugene Elutin
Posted Tuesday, October 16, 2012 5:09 AM
SSCrazy
Group: General Forum Members
Last Login: Today @ 2:43 AM
Points: 2,541,
Visits: 4,373
...
now I want to set superkey on (VENDORID+ADDRESS+CITY) which identify unique record.
...
Why three of them? Are you saying that VENDORID in your VENDOR table is not unique by itself?
Or, you want to say that the same Vendor can have different addresses or at the same address you may hold multiple vendors? If so, you better create separate Address and VendorAddress tables to this data in RDBMS way. Address table will have AddressId and address details and VendorAddress will have VendorId and AddressId as a composite PK?
Or, at least, just have separate VendorAddress table to store multiple vendor addresses in your way. Still, it will be way better than storing multiple records of the same vendor in Vendor table...
_____________________________________________
"The only true wisdom is in knowing you know nothing"
"O skol'ko nam otkrytiy chudnyh prevnosit microsofta duh!"
(So many miracle inventions provided by MS to us...)
How to post your question to get the best and quick help
Post #1373141
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.