Related
Sometimes, there are certain tables in an application with only one column in each of them. Data of records within the respective columns are unique. Examples are: a table for country names, a table for product names (up to 60 characters long, say), a table for company codes (3 characters long and determined by the user), a table for address types (say, billing, delivery), etc.
For tables like these, as the records are unique and not null, the only column can be used as the primary key, technically speaking.
So my question is, is it good enough to use that column as the primary key for the table? Or, is it still desirable to add another column (country_id, product_id, company_id, addresstype_id) as the primary key for the table? Why?
Thanks in advance for any advice.
there is always a debate between using surrogate keys and composite keys as primary key. using composite primary keys always introduces some complexity to your database design so to your application.
think that you have another table which is needed to have direct relationship between your resulting table (billing table). For the composite key scenario you need to have 4 columns in your related table in order to connect with the billing table. On the other hand, if you use surrogate keys, you will have one identity column (simplicity) and you can create unique constraint on (country_id, product_id, company_id, addresstype_id)
but it is hard to say this approach is better then the other one because they both have Pros and Cons.
You can check This for more information
I have a table with employee_name,state,city and zip. I have to join using separate city, state and zip table and one table with all city,state and zip columns.
So which columns should I create index on: city,state,zip separately or a combined index on city,state and zip.
This is a theoretical question so please help me understand the indexes and the performance issues.
If I understand your question, what you need is a numerical primary key column on the City State Zip table. Then the table with employee_name has a column with the appropriate key from from the other table. The City, State Zip table of course has an index on the primary key column. You may also want an index on the employee_name column.
Although it's possible, for efficiency purposes one normally would not throw an index across three text columns. That would make for a rather large index. So we create what is called a surrogate key. In this case, as I suggested, the surrogate key should be an simple integer. Three text columns, City, State, Zip together form what is called the natural key. But this natural keys actually contains redundant information that increases its size. For example, their is a dependency between zip code and state.
I need to understand the difference between super key and composite key. The examples I found made more confused. Can you please simply clarify what is the difference? Thanks
The accepted answer is not entirely accurate...
A superkey is any set of columns that, combined together, are unique. There are typically many superkeys per table and same column may be shared by many superkeys. They are not very useful by themselves, but are more of a mental tool for identifying candidate keys (see below).
A candidate key is a minimal superkey - if any column is removed it would no longer be unique. There are typically significantly fewer candidate keys than superkeys.
A key is just a synonym for a candidate key.
A composite1 key is a key that has more than one column. In other words, it's a minimal superkey that has multiple columns.
Few more points:
Every key is unique, so calling it "unique key" is redundant. Just "key" is enough.
At the DBMS level, a key is enforced through a PRIMARY KEY or UNIQUE2 constraint.
An index is usually present underneath the key (PRIMARY KEY or UNIQUE constraint), for performance reasons. But despite often going together, key and index are separate concepts: key is a logical concept (changes the meaning of data) and index is a physical concept (doesn't change the meaning of data, just performance).
1 Aka. compound, complex or concatenated.
2 On NOT NULL columns.
Yes, I agree with #Branko, the accepted answer is not the accurate and not clear.
I'll take example of an Employee table:
CREATE TABLE Employee (
Employee ID,
FullName,
SSN,
DeptID
);
And to know difference b/w Super & Candidate keys, let's check first what are other types of keys?
1. Candidate Key: are individual columns in a table that qualifies for uniqueness of all the rows. Here in Employee table EmployeeID & SSN are Candidate keys.
2. Primary Key: is the columns you choose to maintain uniqueness in a table. Here in Employee table you can choose either EmployeeID or SSN columns, EmployeeID is preferable choice, as SSN is a secure value.
3. Alternate Key: Candidate column other the Primary column, like if EmployeeID is PK then SSN would be the Alternate key.
4. Super Key: If you add any other column/attribute to a Primary Key then it become a super key, like EmployeeID + FullName is a Super Key.
5. Composite Key: If a table don't have any individual columns that qualifies for a Candidate key, then you have to select 2 or more columns to make a row unique. Like if there is no EmployeeID or SSN columns, then you can make FullName + DateOfBirth as Composite primary Key. But still there can be a narrow chance of duplicate row.
Reference
A superkey is a set of one or more attributes that, taken collectively, allow us to identify uniquely an entity in the entity set.
For example, the customer-id attribute of the
entity set customer is sufficient to distinguish one customer entity from another. Thus,customer-id is a superkey.
Composite Key is a combination of more than one fields/columns of a table. It can be a Candidate key, Primary key.
A super key uniquely identifies a row. It could be made up of one column or many. A composite key is a key made of more than one column.
If a Super Key is made of more than one column it is also a composite.
If a composite key uniquely identifies a row it is also a Super key.
I don't see the name 'Super key' used too much: it's usually just called a 'Unique key'.
I have a table with 8 columns and would like to know the smallest possible unique key for this table. (there are no indexes).
This is as distinct as it gets:
select count(*)
from (select distinct id1, id2, id3,
id4, id5, id6,
id7, id8
from mytable);
Is there a quick and easy way to figure out what column combination is unique for this table? How to proceed?
No, there is no quick and easy way as people have said; as Barmar commented:
Any answer you get will be dependent on the data that happens to be loaded at the time. Any change made to the table could invalidate the result
Additionally you have not previously had a primary key searching for uniqueness could easily come up with a false positive. You haven't been enforcing uniqueness so the set of columns that should be unique might not be.
A unique key is determined by the data within your table. You need to understand the data in order to determine what should be unique.
There should be a natural way of having a unique key, i.e. if you've got a table of OS users then the unique key should probably be their username. Equally, if you have a table of employees there's no way to guarantee uniqueness across employee name (or any other attribute or set of attributes) so you will need to create a surrogate key.
Only you can determine this; study your data and you should be able to work it out.
Generally:
Every table should have a primary key; should should be created at the same time as the table.
There is nothing more important than understanding the data within your database. You are not able to effectively use the database until you understand what it is that you're looking at.
Is it that a primary key is the selected candidate key chosen for a given table?
Candidate Key – A Candidate Key can be any column or a combination of columns that can qualify as unique key in database. There can be multiple Candidate Keys in one table. Each Candidate Key can qualify as Primary Key.
Primary Key – A Primary Key is a column or a combination of columns that uniquely identify a record. Only one Candidate Key can be Primary Key.
More on this link with example
John Woo's answer is correct, as far as it goes. Here are a few additional points.
A primary key is always one of the candidate keys. Fairly often, it's the only candidate.
A table with no candidate keys does not represent a relation. If you're using the relational model to help you build a good database, then every table you design will have at least one candidate key.
The relational model would be complete without the concept of primary key. It wasn't in the original presentation of the relational model. As a practical matter, the use of foreign key references without a declared primary key leads to a mess. It could be a logically correct mess, but it's a mess nonetheless. Declaring a primary key lets the DBMS help you enforce the data rules. Most of the time, having the DBMS help you enforce the data rules is a good thing, and well worth the cost.
Some database designers and some users have some mental confusion about whether the primary key identifies a row (record) in a table or an instance of an entity in the subject matter that the table represents. In an ideal world, it's supposed to do both, and there should be a one-for-one correspondence between rows in an entity table and instances of the corresponding entity.
In the real world, things get screwed up. Somebody enters the same new employee twice, and the employee ends up with two ids. Somebody gets hired, but the data entry slips through the cracks in some manual process, and the employee doesn't get an id, until the omission is corrected. A database that does not collapse the first time things get screwed up is more robust than one that does.
Primary key -> Any column or set of columns that can uniquely identify a record in the table is a primary key. (There can be only one Primary key in the table)
Candidate key -> Any column or set of columns that are candidate to become primary key are Candidate key. (There can be one or more candidate key(s) in the table, if there is only one candidate key, it can be chosen as Primary key)
A Primary key is a special kind of index in that:
there can be only one;
it cannot be nullable
it must be unique.
Candidate keys are selected from the set of super keys, the only thing we take care while selecting the candidate key is: It should not have any redundant attribute.
Example of an Employee table:
Employee (
Employee ID,
FullName,
SSN,
DeptID
)
Candidate Key: are individual columns in a table that qualifies for the uniqueness of all the rows. Here in Employee table EmployeeID & SSN are Candidate keys.
Primary Key: are the columns you choose to maintain uniqueness in a table. Here in Employee table, you can choose either EmployeeID or SSN columns, EmployeeID is a preferable choice, as SSN is a secure value.
Alternate Key: Candidate column other the Primary column, like if EmployeeID is PK then SSN would be the Alternate key.
Super Key: If you add any other column/attribute to a Primary Key then it becomes a super key, like EmployeeID + FullName, is a Super Key.
Composite Key: If a table does not have a single column that qualifies for a Candidate key, then you have to select 2 or more columns to make a row unique. Like if there is no EmployeeID or SSN columns, then you can make FullName + DateOfBirth as Composite primary Key. But still, there can be a narrow chance of duplicate row.
There is no difference. A primary key is a candidate key. By convention one candidate key in a relation is usually chosen to be the "primary" one but the choice is essentially arbitrary and a matter of convenience for database users/designers/developers. It doesn't make a "primary" key fundamentally any different to any other candidate key.
A table can have so many column which can uniquely identify a row. This columns are referred as candidate keys, but primary key should be one of them because one primary key is enough for a table. So selection of primary key is important among so many candidate key. Thats the main difference.
Think of a table of vehicles with an integer Primary Key.
The registration number would be a candidate key.
In the real world registration numbers are subject change so it depends somewhat on the circumstances what might qualify as a candidate key.
Primary key -> Any column or set of columns that can uniquely identify a record in the table is a primary key. (There can be only one Primary key in the table) and
the candidate key-> the same as Primary key but the Primary Key chosen by DB administrator's prospective for example(the primary key the least candidate key in size)
A primary key is a column (or columns) in a table that uniquely identifies the rows in that table.
CUSTOMERS
CustomerNo FirstName LastName
1 Sally Thompson
2 Sally Henderson
3 Harry Henderson
4 Sandra Wellington
For example, in the table above, CustomerNo is the primary key.
The values placed in primary key columns must be unique for each row: no duplicates can be tolerated. In addition, nulls are not allowed in primary key columns.
So, having told you that it is possible to use one or more columns as a primary key, how do you decide which columns (and how many) to choose?
Well there are times when it is advisable or essential to use multiple columns. However, if you cannot see an immediate reason to use multiple columns, then use one. This isn't an absolute rule, it is simply advice. However, primary keys made up of single columns are generally easier to maintain and faster in operation. This means that if you query the database, you will usually get the answer back faster if the tables have single column primary keys.
Next question — which column should you pick? The easiest way to choose a column as a primary key (and a method that is reasonably commonly employed) is to get the database itself to automatically allocate a unique number to each row.
In a table of employees, clearly any column like FirstName is a poor choice since you cannot control employee's first names. Often there is only one choice for the primary key, as in the case above. However, if there is more than one, these can be described as 'candidate keys' — the name reflects that they are candidates for the responsible job of primary key.
If superkey is a big set than candidate key is some smaller set inside big set and primary key any one element(one at a time or for a table) in candidate key set.
First you have to know what is a determinant?
the determinant is an attribute that used to determine another attribute in the same table.
SO the determinant must be a candidate key. And you can have more than one determinant.
But primary key is used to determine the whole record and you can have only one primary key.
Both primary and candidate key can consist of one or more attributes