How to use Unique Composite Key

Question

I have a table

Item(ItemName*, ItemSize*, Price, Notes)

I was making composite key of (ItemName,ItemSize) to uniquely identify item. And

Answer 1

1. You are getting hung up on One Tool to do a task. WIthout understanding that:

   • as Darin states, at the end of the day, SQL is a character-based language
   • any and all commands (Data Manipualtion, or Data Definition as in this case), are executed on the SQL server as character strings
   • there are over one hundred GUI SQL Server Administration tools, from the rubbish that MS keeps churning out every other year, to mature products that keep growing (not replaced or rewritten)
   • you can click or drag or whatever in whatever GUI you use, but when you hit the "save" or "apply" button, the all do the same thing: send an SQL character string to the SQL server for processing

   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.

2. 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.

   • The point is, use one XOR the other, do not use a combination: that leads to creating duplicate indices that you are not even aware of (because they do not show up in the broken MS GUI panel that you are looking at).
     .

   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)..

3. 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.

4. 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 ?