I was experiencing a hard time creating FK relationships in my relational SQL database and after a brief discussion at work, we realized that we have nullable columns which were most likely contributing to the problem. I have always viewed NULL as meaning unassigned, not specified, blank, etc. and have really never seen a problem with that.
The other developers I was speaking with felt that the only way to handle a situation where if a relationship did exist between 2 entities, then you would have to create a table that joins the data from both entities...
It seems intuitive to me at least to say that for a column that contains an ID from another table, if that column is not null, then it must have an ID from the other table, but if it is NULL then that is OK and move on. It seems like this in itself is contradictory to what some say and suggest.
What is the best practice or correct way to handle situations where there could be a relationship between two tables and if a value is specified then it must be in the other table...
A table can have many foreign keys. A foreign key is nullable if any part is nullable. A foreign key value is null if any part is null.
In terms of the relational database model, a NULL value indicates an unknown value. If we widen this theoretical explanation, the NULL value points to an unknown value but this unknown value does not equivalent to a zero value or a field that contains spaces.
They should be avoided to avoid the complexity in select & update queries and also because columns which have constraints like primary or foreign key constraints cannot contain a NULL value.
They are standards in the industry even with the widespread debate. If you decide to use NULLs, always use them uniformly across all of your database tables. Every table must allow them, and you should never use multiple placeholders in different tables. This can lead to bugs in your applications.
It's perfectly acceptable, and it means that, if that column has any value, its value must exist in another table. (I see other answers asserting otherwise, but I beg to differ.)
Think a table of Vehicles and Engines, and the Engines aren't installed in a Vehicle yet (so VehicleID is null). Or an Employee table with a Supervisor column and the CEO of the company.
Update: Per Solberg's request, here is an example of two tables that have a foreign key relationship showing that the foreign key field value can be null.
CREATE TABLE [dbo].[EngineTable](
[EngineID] [int] IDENTITY(1,1) NOT NULL,
[EngineCylinders] smallint NOT NULL,
CONSTRAINT [EngineTbl_PK] PRIMARY KEY NONCLUSTERED
(
[EngineID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[CarTable](
[CarID] [int] IDENTITY(1,1) NOT NULL,
[Model] [varchar](32) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[EngineID] [int] NULL
CONSTRAINT [PK_UnitList] PRIMARY KEY CLUSTERED
(
[CarID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
ALTER TABLE [dbo].[CarTable] WITH CHECK ADD CONSTRAINT [FK_Engine_Car] FOREIGN KEY([EngineID])
REFERENCES [dbo].[EngineTable] ([EngineID])
Insert Into EngineTable (EngineCylinders) Values (4);
Insert Into EngineTable (EngineCylinders) Values (6);
Insert Into EngineTable (EngineCylinders) Values (6);
Insert Into EngineTable (EngineCylinders) Values (8);
-- Now some tests:
Insert Into CarTable (Model, EngineID) Values ('G35x', 3); -- References the third engine
Insert Into CarTable (Model, EngineID) Values ('Sienna', 13); -- Invalid FK reference - throws an error
Insert Into CarTable (Model) Values ('M'); -- Leaves null in the engine id field & does NOT throw an error
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With