Ограничение только для одной записи, отмеченной как значение по умолчанию

С точки зрения нормализации это было бы неэффективным способом сохранить единственный факт.

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

CREATE TABLE [dbo].[Foo](
    [Id] [int] NOT NULL,
 CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
) ON [PRIMARY]
) ON [PRIMARY]

GO

CREATE TABLE [dbo].[DefaultSettings](
    [DefaultFoo] [int] NULL
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[DefaultSettings]  WITH CHECK ADD  CONSTRAINT [FK_DefaultSettings_Foo] FOREIGN KEY([DefaultFoo])
REFERENCES [dbo].[Foo] ([Id])
GO

ALTER TABLE [dbo].[DefaultSettings] CHECK CONSTRAINT [FK_DefaultSettings_Foo]
GO

Вы могли использовать , вставляют/обновляют триггер .

В триггере после того, как вставка или обновление, если количество строк с isDefault = 1 является больше чем 1, то откатывают транзакцию.

Я не знаю о SQLServer. Но если это поддерживает Функциональные Индексы как в Oracle, я надеюсь, что это может быть переведено, в противном случае извините.

можно сделать индекс как это на воображаемом, что значение по умолчанию 1234, столбец DEFAULT_COLUMN, и ID_COLUMN первичный ключ:

CREATE 
UNIQUE 
 INDEX only_one_default 
    ON my_table
     ( DECODE(DEFAULT_COLUMN, 1234, -1, ID_COLUMN) )

Этот DDL создает уникальный индекс, индексирующий -1, если значение DEFAULT_COLUMN 1234 и ID_COLUMN в каком-либо другом случае. Затем если два столбца имеют DEFAULT_COLUMN значение, оно повышает исключение.

CREATE VIEW vOnlyOneDefault
AS
  SELECT 1 as Lock
  FROM <underlying table>
  WHERE Default = 1
GO
CREATE UNIQUE CLUSTERED INDEX IX_vOnlyOneDefault on vOnlyOneDefault (Lock)
GO

у Вас должны будут быть правильные настройки ANSI, включенные для этого.

Это - довольно сложный процесс, который не может быть обработан через простое ограничение.

Мы делаем это через триггер. Однако перед записью триггера, необходимо быть в состоянии ответить на несколько вещей:

мы хотим привести вставку к сбою, если значение по умолчанию существует, измените его на 0 вместо 1 или измените существующее значение по умолчанию на 0 и оставьте этого как 1? что мы хотим сделать, если запись по умолчанию удалена и другой не записи, по умолчанию все еще там? Мы делаем один значением по умолчанию, раз так как мы определяем который?

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

Вам также нужен очень обширный tesing сценарий для этого триггера, прежде чем он пойдет живой. Необходимо протестировать: добавление записи без значения по умолчанию и это - первая запись для того клиента, добавляющего запись со значением по умолчанию, и это - первая запись для того клиента, добавляющего запись без значения по умолчанию, и это не первая запись для того клиента, добавляющего запись со значением по умолчанию, и это не первая запись для того клиента, Обновляющего запись, чтобы иметь значение по умолчанию, когда никакая другая запись не имеет его (предположение, что Вы не требуете, чтобы одна запись всегда была установлена как deafault), Обновление записи для удаления значения по умолчанию, Удаляя запись с deafult Удаление записи без значения по умолчанию, Выполняющего массовую вставку с несколькими ситуациями в данных включая две записи, которые и иметь набор isdefault к 1 и все ситуации, протестированные, когда, рабочая отдельная запись вставляет Выполнение массового обновления с несколькими ситуациями в данных включая две записи, которые и иметь набор isdefault к 1 и все ситуации, протестированные, когда, рабочие отдельные рекордные обновления, Выполняющие массу, удаляют с несколькими ситуациями в данных включая две записи, которые и иметь набор isdefault к 1 и все ситуации, протестированные, когда, рабочая отдельная запись удаляет

Вы могли сделать это через вместо триггера, или если Вы хотите это, поскольку ограничение создает ограничение, которое ссылается на функцию, которая проверяет на строку, которая имеет набор по умолчанию к 1

РЕДАКТИРОВАНИЕ ой, должен быть < =

Create table mytable(id1 int, defaultX bit not null default(0))
go

create Function dbo.fx_DefaultExists()
returns int as 
Begin
    Declare @Ret int
    Set @ret = 0
    Select @ret = count(1) from mytable 
    Where defaultX = 1

    Return @ret
End
GO
Alter table mytable add
CONSTRAINT  [CHK_DEFAULT_SET] CHECK 
 (([dbo].fx_DefaultExists()<=(1)))
GO
Insert into mytable (id1, defaultX) values (1,1)

Insert into mytable (id1, defaultX) values (2,1)

Jones @Andy дал ответ выше самого близкого к моему, но мысль Правило Три , я поместил логику непосредственно в сохраненный proc, который обновляет эту таблицу. Это было моим простым решением. Если я должен обновить таблицу откуда-либо, я перемещу логику в триггер. Одно правило по умолчанию относится к каждому набору записей, определенных FormID и ConfigID:

ALTER proc [dbo].[cpForm_UpdateLinkedReport]
    @reportLinkId int,
    @defaultYN bit,
    @linkName nvarchar(150)
as
if @defaultYN = 1
begin
    declare @formId int, @configId int
    select @formId = FormID, @configId = ConfigID from csReportLink where ReportLinkID = @reportLinkId
    update csReportLink set DefaultYN = 0 where isnull(ConfigID,  @configId) = @configId and FormID = @formId
end
update
    csReportLink
 set
    DefaultYN = @defaultYN,
    LinkName = @linkName
where
    ReportLinkID = @reportLinkId