If I want to add a PRIMARY KEY to an existing column table :
ALTER TABLE table_name
ADD CONSTRAINT column_name_PK PRIMARY KEY (column_name);
Now, If I want to add a NOT NULL to an existing column table :
ALTER TABLE table_name
ALTER column column_name INTEGER(or other data type) NOT NULL;
Isn't NOT NULL a constraint ?
Why for a PRIMARY KEY is ADD CONSTRAINT
and for a NOT NULL is not ADD CONSTRAINT but ALTER COLUMN ?
To my eyes, NOT NULL is also a kind of constraint..
Specifying NOT NULL means 'the column must have a value'. It only means that some value must be present, but it says nothing about what those values should be. Note that in SQL terms, NULL itself is not a value but it is the absence of a value.
A CONSTRAINT on the other hand is a rule for the allowed values. You can even have a constraint on NULL columns, and then such a CONSTRAINT for the allowed values is enforced only if a non-NULL value is present.
You can just use NOT NULL inline when you declare the parameter. Like this:
CREATE TABLE People
(
ID INT NOT NULL,
Name NVARCHAR(100) NOT NULL,
Notes NVARCHAR(MAX) NULL
)
Think of it as the NULL or NOT NULL actually being part of the type declaration. A field that can hold an Integer and also can hold a NULL is a different type than one that can hold an Integer but never a NULL.
Consider
create type IntegerIsSometimesNull from integer null
create type IntegerIsNeverNull from integer not null
go
create table DifferentType ( N IntegerIsSometimesNull,
I IntegerIsNeverNull )
Here we see that NULL and NOT NULL are actually a part of the type declaration.
Consider also that these fields require a different amount of space in the database.
To my eyes, NOT NULL is also a kind of constraint..
Yes. Data Types, NULL-ness, CHECK CONSTRAINTS, and FOREIGN KEY constraints are all concerned with defining the "domain" of the column. A "domain" is the set of possible values for a column, and is a fundamental concept of the relational model.
In most RDBMS systems domains are implemented by a combination of data types and constraints.
Related
I have just inherited a database from another developer, and I have looked through the sys.objects table, filtering by constraints.
What does DF__role_sett__custo__4589517F mean - mainly the ID at the end of the string?
I know that DF_role_sett_custo means default constraint of role_setting_customer, but am not sure of the last ID 4589517f.
If you don't name a constraint when it is created, SQL Server will assign it a random name based on the table and column. It appends a random number so that it doesn't clash with existing constraint names.
In almost all cases, it is best to name a constraint when it is created. It's then easier to refer to the constraint by name in other T-SQL statements.
For instance, in the following create statement
CREATE TABLE dbo.some_table(
some_field INT NOT NULL DEFAULT(5)
);
The default constraint will be assigned a random name. In this statement:
CREATE TABLE dbo.some_table(
some_field INT NOT NULL CONSTRAINT DF_some_table_some_field DEFAULT(5)
);
The default constraint will have the name you assigned to it (i.e. DF_some_table_some_field).
I am creating a database column like this:
Alter table tablename
add column columnname null
add constraint df_columnname default 0
After executing above SQL, the new column is added to table with null values.
Does the constraint df_cloumnname have no meaning here?
Please clarify on this..
If your column is nullable, then adding it with a default constraint has no impact - it can be null, and will remain null. The DEFAULT CONSTRAINT in that case only applies to new rows that are being added (and that do not explicitly specify a value for your column).
If your column were NOT NULL, then the default constraint would be applied right away.
If you're using SQL Server (you didn't specify clearly enough - SQL is the query language - but not a database product...), and you want a nullable column witha default constraint and you want the value to be applied to the existing rows, use this syntax:
ALTER TABLE dbo.tablename
ADD columnname NULL
CONSTRAINT df_columnname DEFAULT 0 WITH VALUES
Add the WITH VALUES to your command and you should get the desired result.
which constraint makes sure a column has some value entered? I am confused between primary key and not null constraint .
A NOT NULL constraint.
All columns that participate in a PK must also not allow NULL but the PK constraint guarantees something more, uniqueness, - i.e. no two rows in the table can have the same value for the primary key.
In SQL Server even though syntactically you can name a NOT NULL constraint in the DDL it is different from other constraints in that no metadata (including even the name) is actually stored for the constraint itself.
CREATE TABLE T
(
X INT CONSTRAINT NotNull NOT NULL
)
Another point I didn't see addressed: NULL and empty string are two very different things, but they are often deemed interchangeable by a large portion of the community.
You can declare a varchar column as NOT NULL but you can still do this:
DECLARE #x TABLE(y VARCHAR(32) NOT NULL);
INSERT #x(y) VALUES('');
So if your goal is to make sure there is a valid value that is neither NULL nor a zero-length string, you can also add a check constraint, e.g.
DECLARE #x TABLE(y VARCHAR(32) NOT NULL CHECK (DATALENGTH(LTRIM(y)) > 0));
NOT NULL
is the condition that a field has a value. You can enforce that a field always have a value entered for every record inserted or updated, making the field NOT NULL in the table definition.
A primary key must meet these three conditions:
The values of the field are NOT NULL.
The values are unique.
The values are immutable.
The database can enforce the first two conditions with a unique index (and a not null condition on the field).
The third condition is not typically enforced by the database. Databases will typically allow changes to primary key fields, so DBAs can "fix" them. So the third condition is more philosophical, in that you agree to use the key for identification, and not write an application which changes the value, unless intended for an administrator to fix the keys.
I have been using field here, but a primary key can be a compound primary key, made up of any combination of fields which meets the conditions. Any combination of fields which matches the first 2 or all 3 conditions is called a candidate key.
Only one candidate key can be used as the primary key. Which one is just an arbitrary choice.
Is there a way to define a constraint using SQL Server 2005 to not only ensure a foreign key exists in another table, but also meets a certain criteria?
For example, say I have two tables:
Table A
--------
Id - int
FK_BId - int
Table B
--------
Id - int
Name - string
SomeBoolean - bit
Can I define a constraint that sayd FK_BId must point to a record in Table B, AND that record in Table B must have SomeBoolean = true? Thanks in advance for any help you can provide.
You can enforce the business rule using a composite key on (Id, SomeBoolean), reference this in table A with a CHECK constraint on FK_BSomeBoolean to ensure it is always TRUE. BTW I'd recommend avoiding BIT and instead using CHAR(1) with domain checking e.g.
CHECK (SomeBoolean IN ('F', 'T'))
The table structure could look like this:
CREATE TABLE B
(
Id INTEGER NOT NULL UNIQUE, -- candidate key 1
Name VARCHAR(20) NOT NULL UNIQUE, -- candidate key 2
SomeBoolean CHAR(1) DEFAULT 'F' NOT NULL
CHECK (SomeBoolean IN ('F', 'T')),
UNIQUE (Id, SomeBoolean) -- superkey
);
CREATE TABLE A
(
Ib INTEGER NOT NULL UNIQUE,
FK_BId CHAR(1) NOT NULL,
FK_BSomeBoolean CHAR(1) DEFAULT 'T' NOT NULL
CHECK (FK_BSomeBoolean = 'T')
FOREIGN KEY (FK_BId, FK_BSomeBoolean)
REFERENCES B (Id, SomeBoolean)
);
I think what you're looking for is out of the scope of foreign keys, but you could do the check in triggers, stored procedures, or your code.
If it is possible to do, I'd say that you would make it a compound foreign key, using ID and SomeBoolean, but I don't think it actually cares what the value is.
In some databases (I can't check SQL Server) you can add a check constraint that references other tables.
ALTER TABLE a ADD CONSTRAINT fancy_fk
CHECK (FK_BId IN (SELECT Id FROM b WHERE SomeBoolean));
I don’t believe this behavior is standard.
I have a text column that should only have 1 of 3 possible strings. To put a constraint on it, I would have to reference another table. Can I instead put the values of the constraint directly on the column without referring to another table?
If this is SQL Server, Oracle, or PostgreSQL, yes, you can use a check constraint.
If it's MySQL, check constraints are recognized but not enforced. You can use an enum, though. If you need a comma-separated list, you can use a set.
However, this is generally frowned upon, since it's definitely not easy to maintain. Just best to create a lookup table and ensure referential integrity through that.
In addition to the CHECK constraint and ENUM data type that other mention, you could also write a trigger to enforce your desired restriction.
I don't necessarily recommend a trigger as a good solution, I'm just pointing out another option that meets your criteria of not referencing a lookup table.
My habit is to define lookup tables instead of using constraints or triggers, when the rule is simply to restrict a column to a finite set of values. The performance impact of checking against a lookup table is no worse than using CHECK constraints or triggers, and it's a lot easier to manage when the set of values might change from time to time.
Also a common task is to query the set of permitted value, for instance to populate a form field in the user interface. When the permitted values are in a lookup table, this is a lot easier than when they're defined in a list of literal values in a CHECK constraint or ENUM definition.
Re comment "how exactly to do lookup without id"
CREATE TABLE LookupStrings (
string VARCHAR(20) PRIMARY KEY
);
CREATE TABLE MainTable (
main_id INT PRIMARY KEY,
string VARCHAR(20) NOT NULL,
FOREIGN KEY (string) REFERENCES LookupStrings (string)
);
Now you can be assured that no value in MainTable.string is invalid, since the referential integrity prevents that. But you don't have to join to the LookupStrings table to get the string, when you query MainTable:
SELECT main_id, string FROM MainTable;
See? No join! But you get the string value.
Re comment about multiple foreign key columns:
You can have two individual foreign keys, each potentially pointing to different rows in the lookup table. The foreign key column doesn't have to be named the same as the column in the referenced table.
My common example is a bug-tracking database, where a bug was reported by one user, but assigned to be fixed by a different user. Both reported_by and assigned_to are foreign keys referencing the Accounts table.
CREATE TABLE Bugs (
bug_id INT PRIMARY KEY,
reported_by INT NOT NULL,
assigned_to INT,
FOREIGN KEY (reported_by) REFERENCES Accounts (account_id),
FOREIGN KEY (assigned_to) REFERENCES Accounts (account_id)
);
In Oracle, SQL Server and PostgreSQL, use CHECK constraint.
CREATE TABLE mytable (myfield INT VARCHAR(50) CHECK (myfield IN ('first', 'second', 'third'))
In MySQL, use ENUM datatype:
CREATE TABLE mytable (myfield ENUM ('first', 'second', 'third'))