Question

What are the situations when you would use a foreign key to a separate table rather than use a boolean (i.e. BIT in SQL Server)

For example would you replace the following two booleans in this table:

engine_sensors
--------------
id (int, primary key)
name (varchar(50))
fault_code (int)
display_warning (boolean) /* if fault show driver a warning */
is_test_sensor (boolean) /* ignore this sensor in diagnostic checks */

e.g. display_warning here might not display the warning to a driver but do display a warning to a mechanic who is testing the engine. So a separate table would be appropriate.

is_test_sensor could be replaced by sensor_type (FK to sensor_types table) which has types of test,live.

Answer 1

Np. Now I see what you are getting at (I think).

If you are asking what I think you are asking than yes, you might want to use a FK to a sensor table and list the sensors. This is typically what I would do…

CREATE TABLE [SensorType](
[Id] [int] NOT NULL,
[Type] [int] NOT NULL,
    [DisplayWarningTo] [int] NOT NULL,
[Description] [nvarchar](100) NULL,
CONSTRAINT [PK_SensorType_Id] PRIMARY KEY (Id),
    CONSTRAINT [FK_SensorType_WarningReceivor] FOREIGN KEY (DisplayWarningTo) REFERENCES WarningReceivor(Id)    
 );

CREATE TABLE [WarningReceiver](
[Id] [int] NOT NULL,
[Receiver] [int] NOT NULL,
CONSTRAINT [PK_WarningReceiver_Id] PRIMARY KEY (Id)
 );

------

INSERT INTO WarningReceiver(Id, Type) VALUES (1, 'Mechanic');
INSERT INTO WarningReceiver(Id, Type) VALUES (2, 'Driver');

INSERT INTO SensorType(Id, Type, DisplayWarningTo) VALUES (1, 'Rear sensor', 2);
INSERT INTO SensorType(Id, Type, DisplayWarningTo) VALUES (2, 'Test sensor', 1);
INSERT INTO SensorType(Id, Type, DisplayWarningTo) VALUES (3, 'Production sensor', 2);

I tend not to use identity columns on ‘type’ things like this and specify my own id which I map directly to a C# enumerated constant like

public enum SensorType
{
    RearSensor = 1,
    TestSensor = 2,
    ProductionSensor = 3
}

Then in your code when you pull out your engine sensor from the database you can just compare against your enum. e.g.

var engine_sensor = // get engine sensor from db.
if (engine_sensor == (int)SensorType.RearSensor)
{
   // do something
}
else if (engine_sensor == (int)SensorType.TestSensor)
{
   // display something to mechanic or whatever
}

I don’t really know what your application domain is, so sorry if this doesn’t make sense.

So to wrap up a couple of points and try and answer your question;

• Yes I do think you are better off with FK’s
• You could just have them as int columns and define the sensors in code as I did with the enum
• I tend to do both
  — define the enum for nice strong typing in code and
  — create a foreign key table to complete my schema in the database. It’s still worth having this for two reasons; 1) When writing sql queries in management studio or something and your looking at your engine_sensors table and see numbers for the sensor type you can join on your FK table to see what the sensors are. Makes things a bit easier

Lastly, if you have a FK table it enforces referential integrity and restricts the values you can put in as sensor types to what you have defined in the sensor type table.

Hope this helps somewhat.