Início / dba / Perguntas / 115431
Accepted
VansFannel
Asked: 2015-09-18 23:56:21 +0800 CST

Uma coluna nula poderia fazer parte de uma chave primária?

  • 772

Estou desenvolvendo um banco de dados SQL Server 2012 e tenho uma pergunta sobre um relacionamento um para zero ou um.

Eu tenho duas tabelas, Codese HelperCodes. Um código pode ter zero ou um código auxiliar. Este é o script sql para criar essas duas tabelas e seus relacionamentos:

CREATE TABLE [dbo].[Code]
(
    [Id] NVARCHAR(20) NOT NULL, 
    [Level] TINYINT NOT NULL, 
    [CommissioningFlag] TINYINT NOT NULL, 
    [SentToRanger] BIT NOT NULL DEFAULT 0, 
    [LastChange] NVARCHAR(50) NOT NULL, 
    [UserName] NVARCHAR(50) NOT NULL, 
    [Source] NVARCHAR(50) NOT NULL, 
    [Reason] NVARCHAR(200) NULL, 
    [HelperCodeId] NVARCHAR(20) NULL,
    CONSTRAINT [PK_Code] PRIMARY KEY CLUSTERED
    (
        [Id] ASC
    ),
    CONSTRAINT [FK_Code_LevelConfiguration]
       FOREIGN KEY ([Level])
        REFERENCES [dbo].[LevelConfiguration] ([Level]),
    CONSTRAINT [FK_Code_HelperCode]
       FOREIGN KEY ([HelperCodeId])
        REFERENCES [dbo].[HelperCode] ([HelperCodeId])
)

CREATE TABLE [dbo].[HelperCode]
(
    [HelperCodeId] NVARCHAR(20) NOT NULL, 
    [Level] TINYINT NOT NULL, 
    [CommissioningFlag] TINYINT NOT NULL, 
    [LastChange] NVARCHAR(50) NOT NULL,
    CONSTRAINT [PK_HelperCode] PRIMARY KEY CLUSTERED
    (
        [HelperCodeId] ASC
    ),
    CONSTRAINT [FK_HelperCode_LevelConfiguration]
       FOREIGN KEY ([Level])
        REFERENCES [dbo].[LevelConfiguration] ([Level])
)

Isso é correto?

Um Code e um HelperCode são entidades diferentes. Um HelperCode pode ser usado (nenhum código faz referência a ele) ou usado (apenas um código faz referência a ele).

Talvez Code.HelperCodeId deve fazer parte da chave primária da tabela de códigos. Mas não tenho certeza se uma coluna nula pode fazer parte de uma primária. Fazendo isso, quero evitar que dois ou mais Codes façam referência ao mesmo HelperCode.

database-design sql-server-2012

2 respostas

  1. Best Answer

    Para responder à pergunta do título, não, todas as colunas primárias precisam ser NOT NULL.

    Mas sem alterar o design das tabelas, você pode adicionar um índice filtrado na Code (HelperCodeId)coluna:

    CREATE UNIQUE INDEX 
    FUX_Code_HelperCodeId
ON dbo.Code 
    (HelperCodeId) 
WHERE 
    HelperCodeId IS NOT NULL ;

    O filtro ( WHERE HelperCodeId IS NOT NULL) é necessário devido à maneira como o SQL-Server trata nulos em restrições exclusivas e índices exclusivos. Sem o filtro, o SQL-Server não permitiria mais de uma linha NULLcom HelperCodeId.

    Um design alternativo seria remover o HelperCodeIdfrom Codee adicionar uma terceira tabela que armazenará os relacionamentos Code- HelperCode. A relação entre as duas entidades parece ser Zero-ou-One-to-Zero-or-One (tanto um Code pode não ter HelperCode quanto um HelperCode pode ser usado por nenhum Code):

    CREATE TABLE [dbo].[Code]
(
    [Id] NVARCHAR(20) NOT NULL, 
    [Level] TINYINT NOT NULL, 
    [CommissioningFlag] TINYINT NOT NULL, 
    [SentToRanger] BIT NOT NULL DEFAULT 0, 
    [LastChange] NVARCHAR(50) NOT NULL, 
    [UserName] NVARCHAR(50) NOT NULL, 
    [Source] NVARCHAR(50) NOT NULL, 
    [Reason] NVARCHAR(200) NULL, 
    -- 
    -- removed:   [HelperCodeId] NVARCHAR(20) NULL,
    -- 
    CONSTRAINT [PK_Code] PRIMARY KEY CLUSTERED
    (
        [Id] ASC
    ),
    CONSTRAINT [FK_Code_LevelConfiguration]
       FOREIGN KEY ([Level])
        REFERENCES [dbo].[LevelConfiguration] ([Level]),
) ;

    HelperCodepermanece inalterado:

    CREATE TABLE [dbo].[HelperCode]
(
    [HelperCodeId] NVARCHAR(20) NOT NULL, 
    [Level] TINYINT NOT NULL, 
    [CommissioningFlag] TINYINT NOT NULL, 
    [LastChange] NVARCHAR(50) NOT NULL,
    CONSTRAINT [PK_HelperCode] PRIMARY KEY CLUSTERED
    (
        [HelperCodeId] ASC
    ),
    CONSTRAINT [FK_HelperCode_LevelConfiguration]
       FOREIGN KEY ([Level])
        REFERENCES [dbo].[LevelConfiguration] ([Level])
) ;

    A tabela adicional terá duas UNIQUErestrições (ou uma primária e uma exclusiva) para garantir que cada Código esteja relacionado a (no máximo) um HelperCode e cada HelperCode esteja relacionado a (no máximo) um Código. Ambas as colunas seriam NOT NULL:

    CREATE TABLE [dbo].[Code_HelperCode]
(
    [CodeId] NVARCHAR(20) NOT NULL, 
    [HelperCodeId] NVARCHAR(20) NOT NULL, 
    CONSTRAINT [UQ_Code_HelperCode_CodeId]
       UNIQUE (CodeId),
    CONSTRAINT [UQ_Code_HelperCode_HelperCodeId]
       UNIQUE (HelperCodeId),
    CONSTRAINT [FK_HelperCode_Code]
       FOREIGN KEY ([CodeId])
        REFERENCES [dbo].[Code] ([Id]),
    CONSTRAINT [FK_Code_HelperCode]
       FOREIGN KEY ([HelperCodeId])
        REFERENCES [dbo].[HelperCode] ([HelperCodeId])
) ;
    • 30

  2. Tente usar uma restrição exclusiva. Supostamente, o padrão ANSI declarou nulos como chave primária inválida, mas nunca vi o padrão e não desejo comprá-lo para verificar isso.

    Não ter chaves nulas parece ser uma daquelas coisas que os desenvolvedores têm uma crença muito difícil de uma forma ou de outra. Minha preferência é usá-los porque acho útil para tabelas de pesquisa contendo dicas de ferramentas e dados relacionados para caixas de combinação que não foram preenchidas.

    Fui ensinado que o valor Null indica que uma variável nunca foi definida e o valor vazio indica que o valor foi definido no passado. É claro que isso cabe ao desenvolvedor definir para o aplicativo, mas acho absurdo permitir chaves primárias vazias, mas não chaves primárias nulas.

    • 0

relate perguntas