Setting a nvarchar as a primary key for datatable relationships - sql

I have data table in the data base with the columnEmail set as nvarchar(100)(becuse i couldn't set it as a primary key when it was nvarchar(MAX).
so it is primary key now, but i cant change it Identity Specification to yes, so I cant make a relationship with this table and another table when this is the primary key.
How can i make a relationship when this is as the primary key?
How can i set the Identity Specification to yes? or is there another way without doing it?
Thanks in advanced


The concept of identity applies to an integer column. The database will automatically assign an increasing number to each new row. An identity column is typically a primary key.
So it makes no sense for a varchar column to be an identity column. SSMS is right in graying the identity section out.
A foreign key can refer to any data type, including a varchar(100). A foreign key has to be indexed. A column that is a primary key always has an index on it.
The foreign key column and the column it references must have the same data type. Perhaps you could post the definition of the two tables you are trying to link.

Related

Oracle IDENTITY column versus PRIMARY KEY

Having trouble finding anything definite about whether it's needed to specify that an IDENTITY column as PRIMARY KEY in Oracle 12.2c. Does an IDENTITY column automatically create an index, like a PK? Is it just being redudant? I do believe you can have an IDENTITY column and separate PK, though we are not doing that.
ID NUMBER AS IDENTITY PRIMARY KEY == ID NUMBER AS IDENTITY ?

Does an IDENTITY column automatically create an index, like a PK?
No. An identity column is just a column auto-populated with a sequentially generated number. You can use it however you want, but the typical use is as a synthetic primary key.
Is it just being redundant?
No.
I do believe you can have an IDENTITY column and separate PK
Yes, you can.
though we are not doing that.
Fine, if you mean you are not having a separate PK column in addition to the identity column. Defining a PK constraint over the identity column would be a good idea.

It's a common mistake to mix logical and physical organization of data.
You successfully mixed 3 orthogonal concepts:
logical: PRIMARY KEY constraint
physical: INDEX
automatic value generation: IDENTITY column
Does an IDENTITY column automatically create an index, like a PK? Is it just being redudant?
Those questions are very version dependent. IDENTITY itself was introduced in Oracle 12.x.
I do believe you can have an IDENTITY column and separate PK, though we are not doing that.
You are correct here.
Auto value generation, logical constraint and physical data organization are orthogonal to each other.

An IDENTITY column can be and often is useful as primary key, but it doesn't have to be.
The identity column is very useful for the surrogate primary key column. When you insert a new row into the identity column, Oracle auto-generates and insert a sequential value into the column.
https://www.oracletutorial.com/oracle-basics/oracle-identity-column/

sql server column has foreign key to itself, and it is also a primary key, how is this possible

I am analysing the database tables and design, I have noticed that there is a table with a column interviewID which is a primary key to the table, it is also a foreign key, the relation says it is a foreign key to itself, how is this even possible. primary key says each value should be unique and not null but foreign key says it has to be one of the existing values? Something wrong with the design? or is there some logic behind this?

When you create a new foreign key in SQL Server Management Studio all controls are set to crazy defaults: a self-referential foreign key on the first column of the table (usually the primary key column). I think somebody did this and just hit save.
It has no purpose whatsoever. Delete it.

Should an SQL Dictionary table have an IDENTITY column

My application needs a generic lookup table Dictionary that should only be referenced by KEY {VARCHAR(N) UNIQUE}
Is there any reason I should not set KEY to be the primary key?

You can definitely use a VARCHAR as a primary key. But being a primary key it would be difficult to update in case of any chance. But as per your need you can definitely use VARCHAR as primary key

How can I replace the existing primary key with a new primary key on my table?

I'm working with a legacy SQL Server database which has a core table with a bad primary key.
The key is of type NVARCHAR(50) and contains an application-generated string based on various things in the table. For obvious reasons, I'd like to replace this key with an auto-incrementing (identity) INT column.
This is a huge database and we're upgrading it piece-by-piece. We want to minimize the changes to tables that other components write to. I figured I could change the table without breaking anything by just:
Adding the new Id column to the table and making it nullable
Filling it with unique integers and making it NOT NULL
Dropping the existing primary key while ensuring there's a uniqueness constraint still on that column
Setting the new Id column to be the new primary key and identity
Item 3 is proving very painful. Because this is a core table, there are a lot of other tables with foreign key constraints on it. To drop the existing primary key, it seems I have to delete all these foreign key constraints and create them again afterwards.
Is there an easier way to do this or will I just have to script everything?

Afraid that is the bad news. We just got through a big project of doing the same type of thing, although our head DBA had a few tricks up his sleeve. You might look at something like this to get your scripts generated for the flipping of the switch:

I once did the same thing and basically used the process you describe. Except of course you have to first visit each other table and add new foreign key pointing to the new column in your base table
So the approach I used was
Add a new column with an auto incrementing integer in the base table, ensure it has a unique index on it (to be replaced later by the primary key)
For each foreign key relationship pointing to the base table add a new column in the child table. (note this can result in adding more than one column in the child table if more than one relationship)
For each instance of a key in the child table enter a value into the new foreign key field(s)
Replace your foreign key relationships such that the new column now serves
Make the new column in the base table the primary
Drop the old primary key in the base table and each old foreign key in the
children.
It is doable and not as hard as it might sound at first. The crux is a series of update statements for the children table of the nature
Update child_table
set new_column = (select new_primary from base)
where old_primary = old_foreign

SQL: To primary key or not to primary key?

I have a table with sets of settings for users, it has the following columns:
UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME
UserID together with Set and Key are unique. So a specific user cannot have two of the same keys in a particular set of settings. The settings are retrieved by set, so if a user requests a certain key from a certain set, the whole set is downloaded, so that the next time a key from the same set is needed, it doesn't have to go to the database.
Should I create a primary key on all three columns (userid, set, and key) or should I create an extra field that has a primary key (for example an autoincrement integer called SettingID, bad idea i guess), or not create a primary key, and just create a unique index?
----- UPDATE -----
Just to clear things up: This is an end of the line table, it is not joined in anyway. UserID is a FK to the Users table. Set is not a FK. It is pretty much a helper table for my GUI.
Just as an example: users get the first time they visit parts of the website, a help balloon, which they can close if they want. Once they click it away, I will add some setting to the "GettingStarted" set that will state they helpballoon X has been disabled. Next time when the user comes to the same page, the setting will state that help balloon X should not be shown anymore.

Having composite unique keys is mostly not a good idea.
Having any business relevant data as primary key can also make you troubles. For instance, if you need to change the value. If it is not possible in the application to change the value, it could be in the future, or it must be changed in an upgrade script.
It's best to create a surrogate key, a automatic number which does not have any business meaning.
Edit after your update:
In this case, you can think of having conceptually no primary key, and make this three columns either the primary key of a composite unique key (to make it changeable).

Should I create a primary key on all three columns (userid, set, and key)
Make this one.
Using surrogate primary key will result in an extra column which is not used for other purposes.
Creating a UNIQUE INDEX along with surrogate primary key is same as creating a non-clustered PRIMARY KEY, and will result in an extra KEY lookup which is worse for performance.
Creating a UNIQUE INDEX without a PRIMARY KEY will result in a HEAP-organized table which will need an extra RID lookup to access the values: also not very good.

How many Key's and Set's do you have? Do these need to be varchar(50) or can they point to a lookup table? If you can convert this Set and Key into SetId and KeyId then you can create your primary key on the 3 integer values which will be much faster.

I would probably try to make sure that UserID was a unique identifier, rather than having duplicates of UserID throughout the code. Composite keys tend to get confusing later on in your code's life.
I'm assuming this is a lookup field for config values of some kind, so you could probably go with the composite key if this is the case. The data is already there. You can guarantee it's uniqueness using the primary key. If you change your mind and decide later that it isn't appropriate for you, you can easily add a SettingId and make the original composite key a unique index.

Create one, separate primary key. No matter what how bussines logic will change, what new rules will have to be applied to your Key VARCHAR(50) field - having one primary key will make you completly independent of bussines logic.

In my experience it all depends how many tables will be using this table as FK information. Do you want 3 extra columns in your other tables just to carry over a FK?
Personally I would create another FK column and put a unique constraint over the other three columns. This makes foreign keys to this table a lot easier to swallow.

I'm not a proponent of composite keys, but in this case as an end of the line table, it might make sense. However, if you allow nulls in any of these three fields becasue one or more of the values is not known at the time of the insert, there can be difficulty and a unique index might be better.

Better have UserID as 32 bit newid() or unique identifier because UserID as int gives a hint to the User of the probable UserID. This will also solve your issue of composite key.