I have a table
Item(ItemName*, ItemSize*, Price, Notes)
I was making composite key of (ItemName,ItemSize) to uniquely identify item. And
ALTER TABLE Items ADD CONSTRAINT uc_name_size UNIQUE (ItemName,ItemSize)
reference from oracle and postgres doc
ALTER TABLE Items ADD UNIQUE INDEX(ItemName, ItemSize);
and here's an article explaining how to achieve the same using SQL Server Management Studio.
You are getting hung up on One Tool to do a task. WIthout understanding that:
Therefore yes, you do need to understand what is happening at the SQL command level if you are going to either adinister the server or model/implement databases. Otherwise you will do unintended things when you click or drag.
SQL has been around for over 30 years, and it has come a long way (it is still very limited, but that is not relevant here). In the old days, we only had
{DROP|CREATE} [UNIQUE] [CLUSTERED] INDEX name ON table (columns, ...)
syntax. As it expanded, more Relational constructs were added, and we have the
ALTER TABLE table {ADD|DROP} {UNIQUE|PRIMARY KEY} CONSTRAINT name (columns,...)
syntax.
Dave Pinal is correct to a point: in terms of data storage structures inside the server ,both INDEX
and CONSTRAINT
syntaxes result in the same thing, an index.
But he is just answering a question, and obviously has not heard about the ISO/IEC/ANSI Standard SQL characterististics that are implied in the newer CONSTRAINT
syntax, which are not implied in the INDEX
syntax (if you use it, you have to specify those parameters explicitly). More important, there are many parameters that can be supplied in the INDEX
syntax which are absent in the CONSTRAINT
syntax. So there are significant differences, which may not be relevant to small servers running in a default state.
Generally people who are inclined towards performance at the physical level, or who have hundreds of tables to administer, use the INDEX
syntax; amd people who distance themselves from the physical us the CONSTRAINT
.
Dave confuses things: there is no such thing as a "Primary Key index". It is either a Primary Key Constraint or a Index (which may be the Primary Key, and have setting relevant to supporting a PK)..
The next thing that will confuse anyone, beginner or otherwise, is that you are used to seeing all kinds of funny drawings that are supposed to depict dat or data models, and they do not. MS is the worst offender, in each different product, there is quite a different funny diagram and set of symbols. There is no commonality or standard; there are symbols that depict importaant aspect of the design, in one picture that you may want in another picture, and you can't get it.
Well, actually there is a Relational Database Modelling Standard, called IDEF1X. But MS have not heard of it. The idea is with a standard, all teh important information regarding the model; the subtleties; etc, are identified in the single model. Many different teams can use the single model. And of course it has its standard set of symbols and notation.
Point is, learn the standards, it will clear up a lot of confusion for you. Then, regardless of what GUI tool you have on your screen today, you will know what you clearly want/have in your data model, and what is going on inside the server.
Point is, re "how do I do this graphically", you do it in any diagramming tool, because you own the model, and you set choose the settings on the tables. No MS GUI has ever, or will ever give that to you.
.
The GUI is not a substitute for knowledge.
Could you explain: if as you state, (ItemName, ItemSize)
forms an unique key on that particular table, on what basis do you think you need instead (ItemName, ItemSize
, plus anything more )
? How can you get more unique than unique ?