Хотелось бы обсудить кое-чего со знающими людьми. Только сильно не пинайте ;)

Суть:
Есть некоторая сущность, скажем ИЗДЕЛИЕ, и у этой сущности есть атрибут, скажем ШИРИНА (в общем случае любой числовой атрибут). При этом ШИРИНА может принимать всего несколько значений. Список этих значений со временем может меняться.

ВАРИАНТ 1
На данный момент, для хранения списка допустимых ШИРИН, заведен отдельный справочник. Т.е. реализована такая схема БД:

CREATE TABLE [dbo].[Product] (
[ProductID] [int] NOT NULL ,
[ProductWidthID] [int] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[ProductWidth] (
[ProductWidthID] [int] NOT NULL ,
[WidthValue] [int] NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] WITH NOCHECK ADD
CONSTRAINT [PK_Product] PRIMARY KEY CLUSTERED
(
[ProductID]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[ProductWidth] WITH NOCHECK ADD
CONSTRAINT [PK_ProductWidth] PRIMARY KEY CLUSTERED
(
[ProductWidthID]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] ADD
CONSTRAINT [FK_Product_ProductWidth] FOREIGN KEY
(
[ProductWidthID]
) REFERENCES [dbo].[ProductWidth] (
[ProductWidthID]
)
GO

ВАРИАНТ 2
С другой стороны, такие атрибуты как ширина (т.е. числовые), гораздо удобнее, хранить непосредственно в таблице ИЗДЕЛИЙ, а для проверки на допустимость достаточно было бы ввести CONSTRAINT. Т.е. получаем такую схему БД:

CREATE TABLE [dbo].[Product] (
[ProductID] [int] NOT NULL ,
[ProductWidth] [int] NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] WITH NOCHECK ADD
CONSTRAINT [PK_Product] PRIMARY KEY CLUSTERED
(
[ProductID]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] WITH NOCHECK ADD
CONSTRAINT [CK_Product] CHECK ([ProductWidth] = 300 or ([ProductWidth] = 240 or ([ProductWidth] = 220 or ([ProductWidth] = 200 or [ProductWidth] = 100))))
GO

В добавок, нужно вести точно такой же список допустимых значений в клиентской части, чтобы при вводе предложить пользователю выбрать значение из списка. В итоге усложняется поддержка системы, т.к. при изменении списка допустимых значений придется вносить исправления и в БД, и в клиентскую часть. При этом если ранее все изменения в справочники мог внести пользователь ИС, то теперь придется привлечь еще и администратора с разработчиком.

ВАРИАНТ 3
В результате, скрестил оба решения и пришел к такому, несколько странному, решению:

CREATE TABLE [dbo].[Product] (
[ProductID] [int] NOT NULL ,
[ProductWidth] [int] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[ProductWidth] (
[WidthValue] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] WITH NOCHECK ADD
CONSTRAINT [PK_Product] PRIMARY KEY CLUSTERED
(
[ProductID]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[ProductWidth] WITH NOCHECK ADD
CONSTRAINT [IX_ProductWidth] UNIQUE NONCLUSTERED
(
[WidthValue]
) ON [PRIMARY]
GO
CREATE TRIGGER CheckWidthValue ON [dbo].[Product]
FOR INSERT, UPDATE
AS
IF NOT EXISTS (SELECT 1 FROM inserted INNER JOIN ProductWidth ON inserted.ProductWidth = ProductWidth.WidthValue)
BEGIN
RAISERROR ('Incorrect value', 16, 1)
END

Т.е. что имеем:
- пользователь имеет возможность самостоятельно изменять список допустимых значений;
- устаревшие записи из справочника можно удалять, не думая об обеспечении целостности;
- в основной таблице храним значения атрибутов, а не ссылки, что упрощает запросы и разработку клиентской части;

Собственно вопросы ;)
Что Вы думаете по поводу всего этого?
Есть ли реальные плюсы в последнем решении? Минусы?
КАКИЕ ЕЩЕ ВОЗМОЖНЫ РЕШЕНИЯ?

it dependsА не проще сделать сразу FOREIGN KEY на ProductWidth вместо триггера?


действительно проще ;)
вот что получилось

CREATE TABLE [dbo].[Product] (
[ProductID] [int] NOT NULL ,
[ProductWidth] [int] NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[ProductWidth] (
[WidthValue] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] WITH NOCHECK ADD
CONSTRAINT [PK_Product] PRIMARY KEY CLUSTERED
(
[ProductID]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[ProductWidth] WITH NOCHECK ADD
CONSTRAINT [IX_ProductWidth] UNIQUE NONCLUSTERED
(
[WidthValue]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Product] ADD
CONSTRAINT [FK_Product_ProductWidth] FOREIGN KEY
(
[ProductWidth]
) REFERENCES [dbo].[ProductWidth] (
[WidthValue]
)
GO

так это решение имеет право на жизнь?
по моему одни плюсы (с учетом foreign key), смущает только то, что ни разу не встречал такого решения..

раз резкой критики не слышно буду пробовать..
все-таки я склоняюсь к использованию триггера для контроля вводимых значений, т.к. это позволит удалять устаревшие записи из списка допустимых значений..
таким образом я строю не таблицу-справочник, а просто список допустимых значений для построения CONSTRAINT, и этот список легко можно получить в клиентской части и дать права пользователю на его редактирование..

basНу как это ширина может иметь набор значений (домен)??? Не совсем понятно. Скорее может иметь ограничения для конкретных типов изделий. Хотя а как же быть с ГОСТом (с нормированным рядом значений), а с другой стороны может быть уникальное изделие не входящее в этот размерный ряд.
На самом деле никакой ширины нет ;) просто чтобы не лезть в дебри предметной области, я так обозначил атрибут..
В общем случае имеем атрибут-число, атрибут имеет набор значений, набор значений может изменяться, желательно чтобы изменение набора производил пользователь..

basА фориген все же лучше. Ну откуда Вы знаете, что значение устаревшее в списке допустимых значений.
Это канечно мне неизвестно, но я могу предположить такую ситуацию, когда возникнет необходимость удалить (скрыть) некоторые значения из списка допустимых. Что делать? вводить дополнительный атрибут? это уже напоминает справочник. Я же планировал сделать список для построения ограничения.
В идеале, имхо, было бы использование именно CONSTRAINT, например так

ALTER TABLE [dbo].[Product] WITH NOCHECK ADD
CONSTRAINT [CK_Product] CHECK ([ProductWidth] IN (SELECT WidthValue FROM ProductWidth))
GO

но к сожалению, MS SQL мне этого не позволяет..
В любом случае, я довольно легко смогу перейти от FOREIGN KEY к триггеру и наоборот.