CREATE TABLE (Transact-SQL)

Artigo
11/19/2024

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure Banco de Dados SQL no Microsoft Fabric

Cria uma nova tabela no banco de dados.

Observação

Para obter referência ao Warehouse no Microsoft Fabric, visite CREATE TABLE (Data Warehouse do Fabric). Para referência ao Azure Synapse Analytics e ao PDW (Analytics Platform System), visite CREATE TABLE (Azure Synapse Analytics).

Convenções de sintaxe de Transact-SQL

Opções de sintaxe

Sintaxe comum

Sintaxe CREATE TABLE simples (comum se não estiver usando opções):

CREATE TABLE
    { database_name.schema_name.table_name | schema_name.table_name | table_name }
    ( { <column_definition> } [ ,... n ] )
[ ; ]

Sintaxe completa

Sintaxe CREATE TABLE baseada em disco:

CREATE TABLE
    { database_name.schema_name.table_name | schema_name.table_name | table_name }
    [ AS FileTable ]
    ( { <column_definition>
        | <computed_column_definition>
        | <column_set_definition>
        | [ <table_constraint> ] [ ,... n ]
        | [ <table_index> ] }
          [ ,... n ]
          [ PERIOD FOR SYSTEM_TIME ( system_start_time_column_name
             , system_end_time_column_name ) ]
      )
    [ ON { partition_scheme_name ( partition_column_name )
           | filegroup
           | "default" } ]
    [ TEXTIMAGE_ON { filegroup | "default" } ]
    [ FILESTREAM_ON { partition_scheme_name
           | filegroup
           | "default" } ]
    [ WITH ( <table_option> [ ,... n ] ) ]
[ ; ]

<column_definition> ::=
column_name <data_type>
    [ FILESTREAM ]
    [ COLLATE collation_name ]
    [ SPARSE ]
    [ MASKED WITH ( FUNCTION = 'mask_function' ) ]
    [ [ CONSTRAINT constraint_name ] DEFAULT constant_expression ]
    [ IDENTITY [ ( seed , increment ) ]
    [ NOT FOR REPLICATION ]
    [ GENERATED ALWAYS AS { ROW | TRANSACTION_ID | SEQUENCE_NUMBER } { START | END } [ HIDDEN ] ]
    [ [ CONSTRAINT constraint_name ] {NULL | NOT NULL} ]
    [ ROWGUIDCOL ]
    [ ENCRYPTED WITH
        ( COLUMN_ENCRYPTION_KEY = key_name ,
          ENCRYPTION_TYPE = { DETERMINISTIC | RANDOMIZED } ,
          ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ) ]
    [ <column_constraint> [ ,... n ] ]
    [ <column_index> ]

<data_type> ::=
[ type_schema_name. ] type_name
    [ ( precision [ , scale ] | max |
        [ { CONTENT | DOCUMENT } ] xml_schema_collection ) ]

<column_constraint> ::=
[ CONSTRAINT constraint_name ]
{
   { PRIMARY KEY | UNIQUE }
        [ CLUSTERED | NONCLUSTERED ]
        [ ( <column_name> [ ,... n ] ) ]
        [
            WITH FILLFACTOR = fillfactor
          | WITH ( <index_option> [ ,... n ] )
        ]
        [ ON { partition_scheme_name ( partition_column_name )
            | filegroup | "default" } ]

  | [ FOREIGN KEY ]
        REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ]
        [ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
        [ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
        [ NOT FOR REPLICATION ]

  | CHECK [ NOT FOR REPLICATION ] ( logical_expression )
}

<column_index> ::=
 INDEX index_name [ CLUSTERED | NONCLUSTERED ]
    [ WITH ( <index_option> [ ,... n ] ) ]
    [ ON { partition_scheme_name ( column_name )
         | filegroup_name
         | default
         }
    ]
    [ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

<computed_column_definition> ::=
column_name AS computed_column_expression
[ PERSISTED [ NOT NULL ] ]
[
    [ CONSTRAINT constraint_name ]
    { PRIMARY KEY | UNIQUE }
        [ CLUSTERED | NONCLUSTERED ]
        [
            WITH FILLFACTOR = fillfactor
          | WITH ( <index_option> [ ,... n ] )
        ]
        [ ON { partition_scheme_name ( partition_column_name )
        | filegroup | "default" } ]

    | [ FOREIGN KEY ]
        REFERENCES referenced_table_name [ ( ref_column ) ]
        [ ON DELETE { NO ACTION | CASCADE } ]
        [ ON UPDATE { NO ACTION } ]
        [ NOT FOR REPLICATION ]

    | CHECK [ NOT FOR REPLICATION ] ( logical_expression )
]

<column_set_definition> ::=
column_set_name XML COLUMN_SET FOR ALL_SPARSE_COLUMNS

<table_constraint> ::=
[ CONSTRAINT constraint_name ]
{
    { PRIMARY KEY | UNIQUE }
        [ CLUSTERED | NONCLUSTERED ]
        ( column_name [ ASC | DESC ] [ ,... n ] )
        [
            WITH FILLFACTOR = fillfactor
           | WITH ( <index_option> [ ,... n ] )
        ]
        [ ON { partition_scheme_name (partition_column_name)
            | filegroup | "default" } ]
    | FOREIGN KEY
        ( column_name [ ,... n ] )
        REFERENCES referenced_table_name [ ( ref_column [ ,... n ] ) ]
        [ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
        [ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
        [ NOT FOR REPLICATION ]
    | CHECK [ NOT FOR REPLICATION ] ( logical_expression )
}

<table_index> ::=
{
    {
      INDEX index_name [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ]
         ( column_name [ ASC | DESC ] [ ,... n ] )
    | INDEX index_name CLUSTERED COLUMNSTORE [ ORDER (column_name [ , ...n ] ) ]
    | INDEX index_name [ NONCLUSTERED ] COLUMNSTORE ( column_name [ ,... n ] )
    }
    [ INCLUDE ( column_name [ ,... n ] ) ]
    [ WHERE <filter_predicate> ]
    [ WITH ( <index_option> [ ,... n ] ) ]
    [ ON { partition_scheme_name ( column_name )
         | filegroup_name
         | default
         }
    ]
    [ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]
}

<table_option> ::=
{
    [ DATA_COMPRESSION = { NONE | ROW | PAGE }
      [ ON PARTITIONS ( { <partition_number_expression> | <range> }
      [ ,... n ] ) ] ]
    [ XML_COMPRESSION = { ON | OFF }
      [ ON PARTITIONS ( { <partition_number_expression> | <range> }
      [ ,... n ] ) ] ]
    [ FILETABLE_DIRECTORY = <directory_name> ]
    [ FILETABLE_COLLATE_FILENAME = { <collation_name> | database_default } ]
    [ FILETABLE_PRIMARY_KEY_CONSTRAINT_NAME = <constraint_name> ]
    [ FILETABLE_STREAMID_UNIQUE_CONSTRAINT_NAME = <constraint_name> ]
    [ FILETABLE_FULLPATH_UNIQUE_CONSTRAINT_NAME = <constraint_name> ]
    [ SYSTEM_VERSIONING = ON
        [ ( HISTORY_TABLE = schema_name.history_table_name
          [ , DATA_CONSISTENCY_CHECK = { ON | OFF } ]
    ) ]
    ]
    [ REMOTE_DATA_ARCHIVE =
      {
        ON [ ( <table_stretch_options> [ ,... n] ) ]
        | OFF ( MIGRATION_STATE = PAUSED )
      }
    ]
    [ DATA_DELETION = ON
          { (
             FILTER_COLUMN = column_name,
             RETENTION_PERIOD = { INFINITE | number { DAY | DAYS | WEEK | WEEKS
                              | MONTH | MONTHS | YEAR | YEARS }
        ) }
    ]
    [ LEDGER = ON [ ( <ledger_option> [ ,... n ] ) ]
    | OFF
    ]
}

<ledger_option>::=
{
    [ LEDGER_VIEW = schema_name.ledger_view_name [ ( <ledger_view_option> [ ,... n ] ) ] ]
    [ APPEND_ONLY = ON | OFF ]
}

<ledger_view_option>::=
{
    [ TRANSACTION_ID_COLUMN_NAME = transaction_id_column_name ]
    [ SEQUENCE_NUMBER_COLUMN_NAME = sequence_number_column_name ]
    [ OPERATION_TYPE_COLUMN_NAME = operation_type_id column_name ]
    [ OPERATION_TYPE_DESC_COLUMN_NAME = operation_type_desc_column_name ]
}

<table_stretch_options> ::=
{
    [ FILTER_PREDICATE = { NULL | table_predicate_function } , ]
      MIGRATION_STATE = { OUTBOUND | INBOUND | PAUSED }
 }

<index_option> ::=
{
    PAD_INDEX = { ON | OFF }
  | FILLFACTOR = fillfactor
  | IGNORE_DUP_KEY = { ON | OFF }
  | STATISTICS_NORECOMPUTE = { ON | OFF }
  | STATISTICS_INCREMENTAL = { ON | OFF }
  | ALLOW_ROW_LOCKS = { ON | OFF }
  | ALLOW_PAGE_LOCKS = { ON | OFF }
  | OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }
  | COMPRESSION_DELAY = { 0 | delay [ Minutes ] }
  | DATA_COMPRESSION = { NONE | ROW | PAGE | COLUMNSTORE | COLUMNSTORE_ARCHIVE }
       [ ON PARTITIONS ( { partition_number_expression | <range> }
       [ ,... n ] ) ]
  | XML_COMPRESSION = { ON | OFF }
      [ ON PARTITIONS ( { <partition_number_expression> | <range> }
      [ ,... n ] ) ]
}

<range> ::=
<partition_number_expression> TO <partition_number_expression>

Sintaxe para tabelas com otimização de memória

Sintaxe CREATE TABLE com otimização de memória:

CREATE TABLE
    { database_name.schema_name.table_name | schema_name.table_name | table_name }
    ( { <column_definition>
    | [ <table_constraint> ] [ ,... n ]
    | [ <table_index> ]
      [ ,... n ] }
      [ PERIOD FOR SYSTEM_TIME ( system_start_time_column_name
        , system_end_time_column_name ) ]
)
    [ WITH ( <table_option> [ ,... n ] ) ]
 [ ; ]

<column_definition> ::=
column_name <data_type>
    [ COLLATE collation_name ]
    [ GENERATED ALWAYS AS ROW { START | END } [ HIDDEN ] ]
    [ NULL | NOT NULL ]
    [ [ CONSTRAINT constraint_name ] DEFAULT memory_optimized_constant_expression ]
    | [ IDENTITY [ ( 1, 1 ) ] ]
    [ <column_constraint> ]
    [ <column_index> ]

<data_type> ::=
 [type_schema_name. ] type_name [ (precision [ , scale ]) ]

<column_constraint> ::=
 [ CONSTRAINT constraint_name ]
{
  { PRIMARY KEY | UNIQUE }
      { NONCLUSTERED
        | NONCLUSTERED HASH WITH ( BUCKET_COUNT = bucket_count )
      }
  [ ( <column_name> [ ,... n ] ) ]
  | [ FOREIGN KEY ]
        REFERENCES [ schema_name. ] referenced_table_name [ ( ref_column ) ]
  | CHECK ( logical_expression )
}

<table_constraint> ::=
 [ CONSTRAINT constraint_name ]
{
   { PRIMARY KEY | UNIQUE }
     {
       NONCLUSTERED ( column_name [ ASC | DESC ] [ ,... n ])
       | NONCLUSTERED HASH ( column_name [ ,... n ] ) WITH ( BUCKET_COUNT = bucket_count )
                    }
    | FOREIGN KEY
        ( column_name [ ,... n ] )
        REFERENCES referenced_table_name [ ( ref_column [ ,... n ] ) ]
    | CHECK ( logical_expression )
}

<column_index> ::=
  INDEX index_name
{ [ NONCLUSTERED ] | [ NONCLUSTERED ] HASH WITH ( BUCKET_COUNT = bucket_count ) }

<table_index> ::=
  INDEX index_name
{   [ NONCLUSTERED ] HASH ( column_name [ ,... n ] ) WITH ( BUCKET_COUNT = bucket_count )
  | [ NONCLUSTERED ] ( column_name [ ASC | DESC ] [ ,... n ] )
      [ ON filegroup_name | default ]
  | CLUSTERED COLUMNSTORE [ WITH ( COMPRESSION_DELAY = { 0 | delay [ Minutes ] } ) ]
      [ ON filegroup_name | default ]

}

<table_option> ::=
{
    MEMORY_OPTIMIZED = ON
  | DURABILITY = { SCHEMA_ONLY | SCHEMA_AND_DATA }
  | SYSTEM_VERSIONING = ON [ ( HISTORY_TABLE = schema_name.history_table_name
        [, DATA_CONSISTENCY_CHECK = { ON | OFF } ] ) ]

}

Argumentos

database_name

É o nome do banco de dados no qual a tabela é criada. database_name precisa especificar o nome de um banco de dados existente. Caso não seja especificado, database_name usará o banco de dados atual como padrão. O logon para a conexão atual precisa estar associado a uma ID de usuário existente no banco de dados especificado por database_name, e essa ID de usuário precisa ter permissões CREATE TABLE.

schema_name

É o nome do esquema ao qual a nova tabela pertence.

table_name

O nome da nova tabela. Os nomes de tabela precisam seguir as regras para identificadores. table_name pode ter no máximo 128 caracteres, exceto nomes de tabelas temporárias locais [nomes com o prefixo de sinal numérico (#)], que não podem exceder 116 caracteres.

AS FileTable

Aplica-se a: SQL Server 2012 (11.x) e posterior.

Cria a nova tabela como uma FileTable. Você não especifica colunas porque uma FileTable tem um esquema fixo. Para obter mais informações, confira FileTables.

column_name como computed_column_expression

É uma expressão que define o valor de uma coluna computada. Uma coluna computada é uma coluna virtual que não está armazenada fisicamente na tabela, a menos que a coluna esteja marcada como PERSISTED. A coluna é computada a partir de uma expressão que usa outras colunas da mesma tabela. Por exemplo, uma coluna computada poderia ter a definição: cost AS price * qty. A expressão pode ser o nome de uma coluna não computada, constante, função, variável e qualquer combinação dessas, conectada por um ou mais operadores. A expressão não pode ser uma subconsulta nem conter tipos de dados de alias.

As colunas computadas podem ser usadas em listas de seleção, cláusulas WHERE, cláusulas ORDER BY ou em qualquer outro local em que expressões regulares possam ser usadas, com as seguintes exceções:

As colunas computadas devem ser marcadas como PERSISTED para participar de uma restrição FOREIGN KEY ou CHECK.
Uma coluna computada poderá ser usada como uma coluna de chave em um índice ou como parte de uma restrição PRIMARY KEY ou UNIQUE, se o valor for definido por uma expressão determinística e o tipo de dados do resultado for permitido nas colunas de índice.

Por exemplo, se a tabela tiver as colunas de inteiros a e b, a coluna computada a + b poderá ser indexada, mas não a coluna computada a + DATEPART(dd, GETDATE()), pois o valor poderá ser alterado nas próximas chamadas.
Uma coluna computada não pode ser o destino de uma instrução INSERT ou UPDATE.

Observação

Cada linha de uma tabela pode ter valores diferentes para as colunas envolvidas em uma coluna computada; sendo assim, a coluna computada pode não ter o mesmo valor para cada linha.

Com base nas expressões usadas, o Mecanismo de Banco de Dados determina automaticamente a nulidade das colunas computadas. O resultado da maioria das expressões será considerado nulo mesmo se somente colunas não nulas estejam presentes, pois a falta de fluxo ou excesso de fluxo produzirá também resultados NULL. Use a função COLUMNPROPERTY com a propriedade AllowsNull para investigar a nulidade de qualquer coluna computada de uma tabela. Uma expressão que permite valor nulo pode se tornar uma expressão que não permite valor nulo pela especificação de ISNULL com a constante check_expression, em que a constante é um valor não nulo substituído para qualquer resultado NULL. A permissão REFERENCES no tipo é necessária para colunas computadas com base em expressões do tipo de dados CLR definido pelo usuário.

PERSISTED

Especifica que o Mecanismo de Banco de Dados do SQL Server armazenará fisicamente os valores computados na tabela e atualizará os valores quando for atualizada qualquer outra coluna da qual a coluna computada depende. A marcação de uma coluna computada como PERSISTED permite a criação de um índice em uma coluna computada que seja determinística, mas não precisa. Para obter mais informações, consulte Indexes on Computed Columns. As colunas computadas usadas como colunas de particionamento de uma tabela particionada precisam ser explicitamente marcadas como PERSISTED. computed_column_expression precisa ser determinística quando PERSISTED é especificado.

ON { partition_scheme | filegroup | "default" }

Especifica o esquema de partição ou grupo de arquivos no qual a tabela é armazenada. Se partition_scheme for especificado, a tabela será uma tabela particionada cujas partições são armazenadas em um conjunto de um ou mais grupos de arquivos especificados em partition_scheme. Se filegroup for especificado, a tabela será criada no grupo de arquivos nomeado. O grupo de arquivos deve existir no banco de dados. Se "default" é especificado ou se ON não é especificado, a tabela é armazenada no grupo de arquivos padrão. O mecanismo de armazenamento de uma tabela especificado em CREATE TABLE não pode ser alterado depois.

ON { partition_scheme | filegroup | "default" } só pode ser especificado em uma restrição PRIMARY KEY ou UNIQUE. Essas restrições criam índices. Se filegroup for especificado, o índice será armazenado no grupo de arquivos nomeado. Se "default" é especificado ou se ON não é especificado, o índice é armazenado no mesmo grupo de arquivos que a tabela. Se a restrição PRIMARY KEY ou UNIQUE criar um índice clusterizado, as páginas de dados da tabela serão armazenadas no mesmo grupo de arquivos que o índice. Se CLUSTERED for especificado ou se a restrição de outra forma criar um índice clusterizado e for especificado um partition_scheme diferente do partition_scheme ou do filegroup da definição da tabela ou vice-versa, somente a definição da restrição será respeitada e as demais serão ignoradas.

Observação

Nesse contexto, default não é uma palavra-chave. É um identificador para o grupo de arquivos padrão e precisa ser delimitado, como em ON "default" ou ON [default]. Se "default" é especificado, a opção QUOTED_IDENTIFIER deve ser definida como ON na sessão atual. Essa é a configuração padrão. Para saber mais, confira SET QUOTED_IDENTIFIER.

Depois de criar uma tabela particionada, considere a configuração da opção LOCK_ESCALATION da tabela como AUTO. Isso pode melhorar a simultaneidade ao permitir que os bloqueios escalem para o nível da partição (HoBT) em vez da tabela. Para obter mais informações, consulte ALTER TABLE.

TEXTIMAGE_ON { filegroup | "default" }

Indica que text, ntext, image, xml, varchar(max), nvarchar(max), varbinary(max) e as colunas de tipo definido pelo usuário CLR (incluindo geometria e geografia) são armazenadas no grupo de arquivos especificado.

TEXTIMAGE_ON não será permitido se não houver colunas de valores grandes na tabela. TEXTIMAGE_ON não poderá ser especificado se partition_scheme for especificado. Se "default" for especificado ou se TEXTIMAGE_ON não for especificado, as colunas de valores grandes serão armazenadas no grupo de arquivos padrão. O armazenamento de qualquer dado de coluna de valor grande especificado em CREATE TABLE não poderá ser alterado depois.

Observação

varchar(max), nvarchar(max), varbinary(max), xml e valores UDT grandes são armazenados diretamente na linha de dados, até o limite de 8 mil bytes, desde que o valor caiba no registro. Se o valor não se ajustar ao registro, um ponteiro será armazenado na linha e o restante será armazenado fora da linha no espaço de armazenamento de LOB. 0 é o valor padrão, que indica que todos os valores são armazenados diretamente na linha de dados.

TEXTIMAGE_ON somente altera o local do "espaço de armazenamento LOB", não afetando o momento em que os dados são armazenados na linha. Use tipos de valor grande sem a opção de linha de sp_tableoption para armazenar todo o valor LOB fora da linha.

Nesse contexto, default não é uma palavra-chave. É um identificador para o grupo de arquivos padrão e precisa ser delimitado, como em TEXTIMAGE_ON "default" ou TEXTIMAGE_ON [default]. Se "default" é especificado, a opção QUOTED_IDENTIFIER deve ser definida como ON na sessão atual. Essa é a configuração padrão. Para saber mais, confira SET QUOTED_IDENTIFIER.

FILESTREAM_ON { partition_scheme_name | filegroup | "default" }

Aplica-se a: SQL Server 2008 R2 (10.50.x) e versões posteriores. O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure não são compatíveis com FILESTREAM.

Especifica o grupo de arquivos para obter dados de FILESTREAM.

Se a tabela contiver dados FILESTREAM e estiver particionada, a cláusula FILESTREAM_ON precisará ser incluída e especificar um esquema de partição de grupos de arquivos FILESTREAM. Esse esquema de partição deve usar a mesma função de partição e as colunas de partição do esquema de partição da tabela; caso contrário, ocorrerá um erro.

Se a tabela não estiver particionada, a coluna FILESTREAM não poderá ser particionada. Dados FILESTREAM da tabela devem ser armazenados em um único grupo de arquivos. Esse grupo de arquivos é especificado na cláusula FILESTREAM_ON.

Se a tabela não estiver particionada e a cláusula FILESTREAM_ON não for especificada, será usado o grupo de arquivos FILESTREAM cuja propriedade DEFAULT estiver definida. Se não houver um grupo de arquivos FILESTREAM, ocorrerá um erro.

Como ocorre com ON e TEXTIMAGE_ON, o valor definido por CREATE TABLE para FILESTREAM_ON não pode ser alterado, exceto nos seguintes casos:

Uma instrução CREATE INDEX converte um heap em um índice clusterizado. Nesse caso, um outro grupo de arquivos FILESTREAM, um esquema de partição ou NULL pode ser especificado.
Uma instrução DROP INDEX converte um índice clusterizado em um heap. Neste caso, outro grupo de arquivos FILESTREAM, um esquema de partição ou "default" pode ser especificado.

O grupo de arquivos da cláusula FILESTREAM_ON <filegroup>, ou cada grupo de arquivos FILESTREAM nomeado no esquema de partição, deve ter um arquivo definido para o grupo de arquivos. Esse arquivo deve ser definido usando uma instrução CREATE DATABASE ou ALTER DATABASE; caso contrário, ocorrerá um erro.

Para ver artigos sobre FILESTREAM relacionados, confira Objeto binário grande – Dados de blob.

[ type_schema_name. ] type_name

Especifica o tipo de dados da coluna e o esquema ao qual ele pertence. Para tabelas baseadas em disco, use um dos seguintes tipos de dados:

Um tipo de dados do sistema
Um tipo de alias com base em um tipo de dados do sistema do SQL Server. Os tipos de dados do alias são criados com a instrução CREATE TYPE antes que possam ser usados em uma definição de tabela. A atribuição NULL ou NOT NULL para um tipo de dados do alias pode ser substituída durante a instrução CREATE TABLE. Contudo, não é possível alterar a especificação do tamanho. O tamanho de um tipo de dados de alias não pode ser especificado na instrução CREATE TABLE.
Um tipo de dados CLR definido pelo usuário. Os tipos de dados CLR definidos pelo usuário são criados com a instrução CREATE TYPE antes que possam ser usados em uma definição de tabela. Para criar uma coluna baseada em um tipo de dados CLR definido pelo usuário, é necessária a permissão REFERENCES para o tipo.

Se type_schema_name não for especificado, o Mecanismo de Banco de Dados do SQL Server fará referência a type_name na seguinte ordem:

O tipo de dados de sistema SQL Server.
O esquema padrão do usuário atual no banco de dados atual.
O esquema dbo no banco de dados atual.

Para tabelas com otimização de memória, veja Tipos de dados compatíveis para OLTP in-memory para obter uma lista dos tipos de sistema compatíveis.

precisão

A precisão do tipo de dados especificado. Para obter mais informações sobre valores de precisão válidos, veja Precisão, escala e comprimento.
scale

A escala do tipo de dados especificado. Para obter mais informações sobre valores de escala válidos, veja Precisão, escala e comprimento.
max

Aplica-se apenas aos tipos de dados varchar, nvarchar e varbinary para armazenar 2^31 bytes de caractere e dados binários e 2^30 bytes de dados Unicode.

CONTENT

Especifica que cada instância do tipo de dados xml em column_name pode conter vários elementos de nível superior. CONTENT aplica-se apenas a tipo de dados xml e poderá ser especificado somente se xml_schema_collection também for especificado. Caso não seja especificado, CONTENT será o comportamento padrão.

DOCUMENT

Especifica que cada instância do tipo de dados xml em column_name pode conter apenas um elemento de nível superior. DOCUMENT aplica-se apenas a tipo de dados xml e poderá ser especificado somente se xml_schema_collection também for especificado.

xml_schema_collection

Aplica-se apenas ao tipo de dados xml para associar uma coleção de esquemas XML ao tipo. Antes de digitar uma coluna xml em um esquema, o esquema deve ser criado primeiramente no banco de dados com CREATE XML SCHEMA COLLECTION.

DEFAULT

Especifica o valor fornecido para a coluna quando um valor não for fornecido explicitamente durante uma inserção. As definições de DEFAULT podem ser aplicadas a qualquer coluna, com exceção daquelas definidas como timestamp ou daquelas com a propriedade IDENTITY. Se um valor padrão for especificado para uma coluna de tipo definido pelo usuário, o tipo deverá ser compatível com uma conversão implícita de constant_expression para o tipo definido pelo usuário. As definições DEFAULT serão removidas quando a tabela for descartada. Somente um valor constante, como uma cadeia de caracteres, uma função de escalar (seja de sistema, definida pelo usuário ou CLR) ou NULL, pode ser usado como padrão. Para manter a compatibilidade com versões anteriores do SQL Server, um nome de restrição pode ser atribuído a um DEFAULT.

constant_expression

É uma constante, NULL ou uma função de sistema usada como o valor padrão da coluna.
memory_optimized_constant_expression

É uma constante, NULL, ou uma função de sistema com suporte usada como o valor padrão da coluna. Deve haver suporte nos procedimentos armazenados compilados de modo nativo. Para obter mais informações sobre as funções integradas em procedimentos armazenados compilados nativamente, veja Recursos compatíveis em módulos T-SQL compilados nativamente.

IDENTITY

Indica que a nova coluna é uma coluna de identidade. Quando uma nova linha é adicionada à tabela, o Mecanismo de Banco de Dados fornece um valor incremental exclusivo para a coluna. Geralmente, as colunas de identidade são usadas com restrições PRIMARY KEY para servir como o identificador exclusivo de linha para a tabela. A propriedade IDENTITY pode ser atribuída às colunas tinyint, smallint, int, bigint, decimal(p,0) ou numeric(p,0). Apenas uma coluna de identidade pode ser criada por tabela. Padrões associados e restrições DEFAULT não podem ser usados com uma coluna de identidade. Devem ser especificados tanto o valor de semente como o de incremento ou nenhum dos dois. Se nenhum for especificado, o padrão será (1,1).

seed

O valor usado para a primeira linha carregada na tabela.
increment

É o valor de incremento adicionado ao valor de identidade da linha anterior carregada.

NOT FOR REPLICATION

Na instrução CREATE TABLE, a cláusula NOT FOR REPLICATION pode ser especificada para a propriedade IDENTITY e para restrições FOREIGN KEY e CHECK. Se essa cláusula for especificada para a propriedade IDENTITY, os valores não serão incrementados em colunas de identidade quando os agentes de replicação executarem inserções. Se essa cláusula for especificada para uma restrição, ela não será aplicada quando os agentes de replicação executarem operações insert, update ou delete.

GENERATED ALWAYS AS { ROW | TRANSACTION_ID | SEQUENCE_NUMBER } { START | END } [ HIDDEN ] [ NOT NULL ]

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Especifica uma coluna usada pelo sistema para registrar automaticamente as informações sobre as versões de linha na tabela e a tabela de histórico (se a tabela tiver a versão do sistema e uma tabela de histórico). Use esse argumento com o parâmetro WITH SYSTEM_VERSIONING = ON para criar tabelas com controle de versão do sistema: tabelas temporais ou do razão. Para saber mais, confira Tabelas do razão atualizáveis e Tabelas temporais.

Parâmetro	Tipo de dados exigido	Nulidade obrigatória	Descrição
ROW	datetime2	START: `NOT NULL` END: `NOT NULL`	A hora de início em que uma versão de linha é válida (START) ou a hora de término em que uma versão de linha é válida (END). Use esse argumento com o argumento `PERIOD FOR SYSTEM_TIME` para criar uma tabela temporal.
TRANSACTION_ID	BIGINT	START: `NOT NULL` END: `NULL`	Aplica-se a: SQL Server 2022 (16.x) e posterior e Banco de Dados SQL do Azure. A ID da transação que cria (START) ou invalida (END) uma versão de linha. Em caso de tabela do razão, a ID fará referência à linha na exibição sys.database_ledger_transactions
SEQUENCE_NUMBER	BIGINT	START: `NOT NULL` END: `NULL`	Aplica-se a: SQL Server 2022 (16.x) e posterior e Banco de Dados SQL do Azure. O número de sequência de uma operação que cria (START) ou exclui (END) uma versão de linha. Esse valor é exclusivo na transação.

Se você tentar especificar uma coluna que não atenda aos requisitos de tipo de dados ou de nulidade acima, o sistema vai gerar um erro. Se você não especificar explicitamente a nulidade, o sistema definirá a coluna como NULL ou NOT NULL de acordo com os requisitos acima.

Você pode marcar uma ou ambas as colunas de período com o sinalizador HIDDEN para ocultar implicitamente essas colunas, de modo que SELECT * FROM <table> não retorne um valor para essas colunas. Por padrão, as colunas de período não ficam ocultas. Para serem usadas, colunas ocultas devem ser explicitamente incluídas em todas as consultas que fazem referência direta à tabela temporal. Para alterar o atributo HIDDEN para uma coluna de período existente, PERIOD deve ser descartado e recriado com um sinalizador oculto diferente.

INDEX index_name [ CLUSTERED | NONCLUSTERED ] ( column_name [ ASC | DESC ] [ ,... n ] )

Aplica-se a: SQL Server 2014 (12.x) e posterior e Banco de Dados SQL do Azure.

Especifica a criação de um índice na tabela. Isso pode ser um índice clusterizado ou um índice não clusterizado. O índice conterá as colunas listadas e classificará os dados em ordem crescente ou decrescente.

INDEX index_name CLUSTERED COLUMNSTORE

Aplica-se a: SQL Server 2014 (12.x) e posterior e Banco de Dados SQL do Azure.

Especifica o armazenamento de toda a tabela em formato de coluna com um índice columnstore clusterizado. Isso sempre inclui todas as colunas na tabela. Os dados não estão classificados em ordem alfabética ou numérica, pois as linhas são organizadas para obter benefícios de compactação de columnstore.

No Azure Synapse Analytics, no PDW (Analytics Platform System) e no SQL Server 2022 (16.x) e versões posteriores, você pode determinar a ordem das colunas para um índice columnstore clusterizado. Para obter mais informações, consulte Usar um índice columnstore clusterizado ordenado para tabelas grandes do data warehouse.

INDEX index_name [ NONCLUSTERED ] COLUMNSTORE ( column_name [ ,... n ] )

Aplica-se a: SQL Server 2014 (12.x) e posterior e Banco de Dados SQL do Azure.

Especifica a criação de um índice não clusterizado columnstore na tabela. A tabela subjacente pode ser um heap rowstore ou um índice clusterizado, ou pode ser um índice columnstore clusterizado. Em todos os casos, a criação de um índice columnstore não clusterizado em uma tabela armazena uma segunda cópia dos dados para as colunas no índice.

O índice columnstore não clusterizado é armazenado e gerenciado como um índice columnstore clusterizado. Isso é chamado de índice columnstore não clusterizado porque as colunas podem ser limitadas e existem como um índice secundário em uma tabela.

ON partition_scheme_name ( column_name )

Especifica o esquema de partição que define os grupos de arquivos nos quais as partições de um índice particionado serão mapeadas. O esquema de partição deve existir no banco de dados com a execução de CREATE PARTITION SCHEME ou ALTER PARTITION SCHEME. column_name especifica a coluna com relação à qual um índice particionado será particionado. Essa coluna precisa corresponder ao tipo de dados, ao comprimento e à precisão do argumento da função de partição que partition_scheme_name está usando. column_name não é restrito às colunas na definição de índice. Qualquer coluna da tabela base pode ser especificada, exceto que, ao particionar um índice UNIQUE, column_name deve ser escolhido entre aqueles usados como chave exclusiva. Essa restrição permite ao Mecanismo de Banco de Dados verificar a exclusividade de valores de chave em uma única partição apenas.

Observação

Ao particionar um índice clusterizado não exclusivo, por padrão, o Mecanismo de Banco de Dados adiciona a coluna de particionamento à lista de chaves de índices clusterizados, se ela já não estiver especificada. Ao particionar um índice não clusterizado e não exclusivo, o Mecanismo de Banco de Dados adiciona a coluna de particionamento como uma coluna não chave (incluída) do índice, se ela já não estiver especificada.

Se partition_scheme_name ou filegroup não for especificado e a tabela estiver particionada, o índice será colocado no mesmo esquema de partição, usando a mesma coluna de particionamento que a tabela subjacente.

Observação

Não é possível especificar um esquema de particionamento em um índice XML. Se a tabela base for particionada, o índice XML usará o mesmo esquema de partição que a tabela.

Para obter mais informações sobre particionamento de índices, consulte Tabelas e índices particionados.

ON filegroup_name

Cria o índice especificado no grupo de arquivos especificado. Se nenhum local for especificado e a tabela ou exibição não for particionada, o índice usará o mesmo grupo de arquivos que a tabela ou exibição subjacente. O grupo de arquivos já deve existir.

ON "padrão"

Cria o índice especificado no grupo de arquivos padrão.

Observação

[ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

Aplica-se a: SQL Server 2008 R2 (10.50.x) e versões posteriores.

Especifica a colocação de dados FILESTREAM para a tabela quando um índice clusterizado é criado. A cláusula FILESTREAM_ON permite mover os dados FILESTREAM para outro grupo de arquivos ou esquema de partição FILESTREAM.

filestream_filegroup_name é o nome de um grupo de arquivos FILESTREAM. O grupo de arquivos deve ter um arquivo definido para o grupo de arquivos usando uma instrução CREATE DATABASE ou ALTER DATABASE; caso contrário, será gerado um erro.

Se a tabela for particionada, a cláusula FILESTREAM_ON precisará ser incluída e especificar um esquema de partição de grupos de arquivos FILESTREAM que use a mesma função de partição e as mesmas colunas de partição que o esquema de partição da tabela. Caso contrário, será gerado um erro.

Se a tabela não estiver particionada, a coluna FILESTREAM não poderá ser particionada. Os dados FILESTREAM da tabela precisam ser armazenados em um único grupo de arquivos que é especificado na cláusula FILESTREAM_ON.

FILESTREAM_ON NULL poderá ser especificado em uma instrução CREATE INDEX se um índice clusterizado estiver sendo criado e a tabela não contiver uma coluna FILESTREAM.

Para obter mais informações, veja FILESTREAM.

ROWGUIDCOL

Indica que a nova coluna é uma coluna de GUID de linha. Somente uma coluna uniqueidentifier por tabela pode ser designada como a coluna ROWGUIDCOL. A aplicação da propriedade ROWGUIDCOL permite que a coluna seja referenciada usando $ROWGUID. A propriedade ROWGUIDCOL pode ser atribuída somente a uma coluna uniqueidentifier. As colunas de tipo de dados definido pelo usuário não podem ser designadas com ROWGUIDCOL.

A propriedade ROWGUIDCOL não impõe exclusividade dos valores armazenados na coluna. ROWGUIDCOL também não gera valores automaticamente para novas linhas inseridas na tabela. Para gerar valores exclusivos para cada coluna, use a função NEWID ou NEWSEQUENTIALID em instruções INSERT ou use essas funções como o padrão para a coluna.

ENCRYPTED WITH

Especifica as colunas de criptografia usando o recurso Always Encrypted.

COLUMN_ENCRYPTION_KEY = key_name

Especifica a chave de criptografia de coluna. Para obter mais informações, veja CREATE COLUMN ENCRYPTION KEY.
ENCRYPTION_TYPE = { DETERMINISTIC | RANDOMIZED }

A criptografia determinística usa um método que sempre gera o mesmo valor criptografado para qualquer valor de texto sem formatação. Usar criptografia determinística permite pesquisar usando comparação de igualdade, agrupamento e junção de tabelas usando junções de igualdade baseadas em valores criptografados, mas também pode permitir que usuários não autorizados adivinhem informações sobre valores criptografados examinando padrões na coluna criptografada. A união de duas tabelas em colunas criptografadas de maneira determinística só é possível se ambas as colunas são criptografadas com a mesma chave de criptografia de coluna. A criptografia determinística deve usar uma ordenação de colunas com uma ordem de classificação binary2 para as colunas de caracteres.

Criptografia aleatória usa um método que criptografa os dados de uma maneira menos previsível. A criptografia aleatória é mais segura, mas impede que cálculos e indexação sejam feitos em colunas criptografadas, a menos que sua instância do SQL Server tenha suporte para Always Encrypted com enclaves seguros. Confira Always Encrypted com enclaves seguros para obter detalhes.

Se você estiver usando o Always Encrypted (sem enclaves seguros), use a criptografia determinística para colunas que serão pesquisadas com parâmetros ou com parâmetros de agrupamento, por exemplo, um número de identificação do governo. Use a criptografia randomizada para dados como número de cartão de crédito, que não são agrupados a outros registros nem usados para unir tabelas, e não são procurados porque você usa outras colunas (como número de transações) para localizar a linha que contém a coluna criptografada de interesse.

Se você está usando o Always Encrypted com enclaves seguros, a criptografia aleatória é um tipo de criptografia recomendado.

As colunas devem ser de um tipo de dados qualificado.
ALGORITHM

Aplica-se a: SQL Server 2016 (13.x) e posterior.

Deve ser 'AEAD_AES_256_CBC_HMAC_SHA_256'.

Para mais informações, incluindo restrições de recursos, veja Always Encrypted.

SPARSE

Indica que a coluna é uma coluna esparsa. O armazenamento de colunas esparsas é otimizado para obter valores nulos. Colunas esparsas não podem ser designadas como NOT NULL. Para obter restrições adicionais e mais informações sobre colunas esparsas, consulte Usar colunas esparsas.

MASKED WITH ( FUNCTION = 'mask_function' )

Aplica-se a: SQL Server 2016 (13.x) e posterior.

Especifica uma máscara de dados dinâmicos. mask_function é o nome da função de mascaramento com os parâmetros apropriados. Quatro funções estão disponíveis:

default()
email()
partial()
random()

Requer a permissão ALTER ANY MASK.

Para parâmetros de função, consulte Máscara de Dados Dinâmicos.

FILESTREAM

Aplica-se a: SQL Server 2008 R2 (10.50.x) e versões posteriores.

Válido somente para colunas varbinary(max) . Especifica o armazenamento FILESTREAM para dados de BLOB varbinary(max) .

A tabela também deve ter uma coluna do tipo de dados uniqueidentifier com o atributo ROWGUIDCOL. Essa coluna não deve permitir valores nulos e deve ter uma restrição de coluna única UNIQUE ou PRIMARY KEY. O valor de GUID da coluna deve ser fornecido por um aplicativo ao inserir dados ou por uma restrição DEFAULT que usa a função NEWID ().

A coluna ROWGUIDCOL não pode ser removida e as restrições relacionadas não podem ser alteradas enquanto há uma coluna FILESTREAM definida para a tabela. A coluna ROWGUIDCOL poderá ser descartada somente depois que a última coluna FILESTREAM for descartada.

Quando o atributo de armazenamento FILESTREAM é especificado para uma coluna, todos os valores da coluna são armazenados em um contêiner de dados FILESTREAM no sistema de arquivos.

COLLATE collation_name

Especifica a ordenação da coluna. O nome da ordenação pode ser um nome de ordenação do Windows ou um nome de ordenação SQL. collation_name é aplicável somente a colunas dos tipos de dados char, varchar, text, nchar, nvarchar e ntext. Se não for especificado, à coluna será atribuída a ordenação do tipo de dados definido pelo usuário, se a coluna for de um tipo de dados definido pelo usuário, ou a ordenação do banco de dados atual.

Para obter mais informações sobre os nomes de ordenação do Windows e do SQL, consulte Nome de ordenação do Windows e Nome de ordenação do SQL.

Para obter mais informações, consulte COLLATE.

CONSTRAINT

É uma palavra-chave opcional que indica o início da definição de uma restrição PRIMARY KEY, NOT NULL, UNIQUE, FOREIGN KEY ou CHECK.

constraint_name

É o nome de uma restrição. Nomes de restrição devem ser exclusivos no esquema ao qual a tabela pertence.
NULL | NOT NULL

Determinam se são permitidos valores nulos na coluna. NULL não é uma restrição estritamente, mas pode ser especificado como NOT NULL. NOT NULL poderá ser especificado para colunas computadas somente se PERSISTED também for especificado.
PRIMARY KEY

É uma restrição que impõe integridade de entidade a uma ou mais colunas especificadas por meio de um índice exclusivo. Somente uma restrição PRIMARY KEY pode ser criada por tabela.
UNIQUE

É uma restrição que fornece integridade de entidade a uma coluna ou a colunas especificadas por meio de um índice exclusivo. Uma tabela pode ter várias restrições UNIQUE.
CLUSTERED | NONCLUSTERED

Indica que um índice clusterizado ou não clusterizado será criado para a restrição PRIMARY KEY ou UNIQUE. O padrão das restrições PRIMARY KEY é CLUSTERED e das restrições UNIQUE é NONCLUSTERED.

Em uma instrução CREATE TABLE, CLUSTERED pode ser especificado apenas para uma restrição. Se CLUSTERED for especificado para uma restrição UNIQUE e uma restrição PRIMARY KEY também for especificada, PRIMARY KEY adotará o padrão de NONCLUSTERED.
FOREIGN KEY REFERENCES

É uma restrição que fornece integridade referencial para os dados na coluna ou nas colunas. As restrições FOREIGN KEY requerem que cada valor na coluna exista na coluna ou colunas referenciadas correspondentes na tabela referenciada. As restrições FOREIGN KEY podem fazer referência somente a colunas que sejam restrições PRIMARY KEY ou UNIQUE na tabela ou colunas referenciadas em um UNIQUE INDEX na tabela referenciada. As chaves estrangeiras em colunas computadas também devem ser marcadas como PERSISTED.
[ [ schema_name. ] referenced_table_name ]

É o nome da tabela referenciada pela restrição FOREIGN KEY e o esquema ao qual ela pertence.
( ref_column [ ,... n ] )

É uma coluna ou uma lista de colunas da tabela referenciada pela restrição FOREIGN KEY.
ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT }

Especifica qual ação ocorrerá nas linhas da tabela criada se essas linhas tiverem uma relação referencial e a linha referenciada for excluída da tabela pai. O padrão é NO ACTION.
NO ACTION

O Mecanismo de Banco de Dados gera um erro e a ação de excluir na linha da tabela pai é revertida.
CASCADE

As linhas correspondentes serão excluídas da tabela de referência se aquela linha for excluída da tabela pai.
SET NULL

Todos os valores que compõem a chave estrangeira serão definidos como NULL se a linha correspondente na tabela pai for excluída. Para que essa restrição seja executada, as colunas de chave estrangeira devem ser anuláveis.
SET DEFAULT

Todos os valores que compõem a chave estrangeira serão definidos como seus valores padrão quando a linha correspondente na tabela pai for excluída. Para que essa restrição seja executada, todas as colunas de chave estrangeira devem ter definições padrão. Se a coluna for anulável e não houver nenhum valor padrão explícito definido, NULL se tornará o valor padrão implícito para a coluna.

Não especifique CASCADE se a tabela for incluída em uma publicação de mesclagem que use registros lógicos. Para obter mais informações sobre registros lógicos, consulte Agrupar alterações em linhas relacionadas com registros lógicos.

ON DELETE CASCADE não poderá ser definido se um gatilho ON DELETE de INSTEAD OF já existir na tabela.

Por exemplo, no banco de dados AdventureWorks2022, a tabela ProductVendor tem uma relação referencial com a tabela Vendor. A chave estrangeira ProductVendor.BusinessEntityID referencia a chave primária Vendor.BusinessEntityID.

Se uma instrução DELETE for executada em uma linha da tabela Vendor e uma ação ON DELETE CASCADE for especificada para ProductVendor.BusinessEntityID, o Mecanismo de Banco de Dados verificará se há uma ou mais linhas dependentes na tabela ProductVendor. Se existir alguma, as linhas dependentes da tabela ProductVendor serão excluídas, além da linha referenciada na tabela Vendor.

Por outro lado, se NO ACTION for especificado, o Mecanismo de Banco de Dados vai gerar um erro e reverter a ação de exclusão da linha Vendor se houver pelo menos uma linha na tabela ProductVendor que a referencie.
ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT }

Especifica a ação que ocorre nas linhas da tabela alterada, quando essas linhas têm uma relação referencial e a linha referenciada for atualizada na tabela pai. O padrão é NO ACTION.
NO ACTION

O Mecanismo de Banco de Dados gera um erro, e a ação de atualizar na linha da tabela pai é revertida.
CASCADE

As linhas correspondentes são atualizadas na tabela de referência quando aquela linha é atualizada na tabela pai.
SET NULL

Todos os valores que compõem a chave estrangeira são definidos como NULL quando a linha correspondente na tabela pai é atualizada. Para que essa restrição seja executada, as colunas de chave estrangeira devem ser anuláveis.
SET DEFAULT

Todos os valores que compõem a chave estrangeira são definidos como seus valores padrão quando a linha correspondente na tabela pai é atualizada. Para que essa restrição seja executada, todas as colunas de chave estrangeira devem ter definições padrão. Se a coluna for anulável e não houver nenhum valor padrão explícito definido, NULL se tornará o valor padrão implícito para a coluna.

Não especifique CASCADE se a tabela for incluída em uma publicação de mesclagem que use registros lógicos. Para obter mais informações sobre registros lógicos, consulte Agrupar alterações em linhas relacionadas com registros lógicos.

ON UPDATE CASCADE, SET NULL ou SET DEFAULT não poderá ser definido se um gatilho ON UPDATE de INSTEAD OF já existir na tabela que está sendo alterada.

Por exemplo, no banco de dados AdventureWorks2022, a tabela ProductVendor tem uma relação referencial com a tabela Vendor: A chave estrangeira ProductVendor.BusinessEntity faz referência à chave primária Vendor.BusinessEntityID.

Se uma instrução UPDATE for executada em uma linha da tabela Vendor e uma ação ON UPDATE CASCADE for especificada para ProductVendor.BusinessEntityID, o Mecanismo de Banco de Dados verificará se há uma ou mais linhas dependentes na tabela ProductVendor. Se existir alguma, as linhas dependentes da tabela ProductVendor serão atualizadas, além da linha referenciada na tabela Vendor.

De modo inverso, se NO ACTION for especificada, o Mecanismo de Banco de Dados vai gerar um erro e reverter a ação de atualização da linha Vendor se houver pelo menos uma linha da tabela ProductVendor que a referencie.
CHECK

Uma restrição que impõe integridade de domínio limitando os possíveis valores que podem ser inseridos em uma ou mais colunas. As restrições CHECK em colunas computadas também devem ser marcadas como PERSISTED.
logical_expression

Uma expressão lógica que retorna TRUE ou FALSE. Tipos de dados de alias não podem fazer parte da expressão.
column_name

É uma coluna, ou lista de colunas, entre parênteses, usada em restrições de tabela para indicar as colunas usadas na definição da restrição.
[ ASC | DESC ]

Especifica a ordem na qual a coluna ou colunas que participam de restrições de tabela são classificadas. O padrão é ASC.
partition_scheme_name

É o nome do esquema de partição que define os grupos de arquivos nos quais as partições de uma tabela particionada serão mapeadas. O esquema de partição deve existir no banco de dados.
[ partition_column_name. ]

Especifica a coluna que servirá de base para o particionamento de uma tabela particionada. A coluna deve corresponder àquela especificada na função de partição que partition_scheme_name está usando em termos de tipo de dados, comprimento e precisão. Uma coluna computada que participa de uma função de partição precisa ser marcada explicitamente como PERSISTED.

Importante

Recomendamos a especificação de NOT NULL na coluna de particionamento das tabelas particionadas e também de tabelas não particionadas que servem de origem e destino para as operações ALTER TABLE...SWITCH. Isso garante que toda restrição CHECK de colunas de particionamento não terão que verificar se existem valores nulos.
WITH FILLFACTOR = fillfactor

Especifica o quanto o Mecanismo de Banco de Dados deve preencher cada página de índice usada para armazenar os dados de índice. Os valores de fillfactor especificados pelo usuário podem ser de 1 a 100. Se o valor não for especificado, o padrão será 0. Os valores de fator de preenchimento 0 e 100 são iguais em todos os aspectos.

Importante

A documentação de WITH FILLFACTOR = fillfactor como a única opção de índice aplicável às restrições PRIMARY KEY ou UNIQUE é mantida para fins de compatibilidade com versões anteriores, mas não será documentada dessa maneira em versões futuras.

column_set_name XML COLUMN_SET FOR ALL_SPARSE_COLUMNS

O nome do conjunto de colunas. Um conjunto de colunas é uma representação em XML sem-tipo que combina todas as colunas esparsas de uma tabela em uma saída estruturada. Para obter mais informações sobre conjuntos de colunas, veja Usar conjuntos de colunas.

PERIOD FOR SYSTEM_TIME ( system_start_time_column_name , system_end_time_column_name )

Aplica-se a: SQL Server 2016 (13.x) e posterior e Banco de Dados SQL do Azure.

Especifica os nomes das colunas que o sistema usará para registrar o período para o qual um registro é válido. Use esse argumento com os argumentos GENERATED ALWAYS AS ROW { START | END } e WITH SYSTEM_VERSIONING = ON para criar uma tabela temporal. Para saber mais, veja Temporal Tables.

COMPRESSION_DELAY

Aplica-se a: SQL Server 2016 (13.x) e posterior e Banco de Dados SQL do Azure.

Para uma otimização de memória, atraso especifica o número mínimo de minutos que uma linha deve permanecer na tabela, inalterada, antes de ser elegível para compactação no índice columnstore. O SQL Server seleciona linhas específicas a serem compactadas de acordo com a hora da última atualização. Por exemplo, se as linhas estiverem sendo alteradas com frequência durante um período de duas horas, você poderá definir COMPRESSION_DELAY = 120 Minutes para garantir que as atualizações sejam concluídas antes de o SQL Server compactar a linha.

Para uma tabela baseada em disco, o atraso especifica o número mínimo de minutos que um rowgroup delta no estado CLOSED precisa permanecer no rowgroup delta antes que o SQL Server possa compactá-lo no rowgroup compactado. Como as tabelas baseadas em disco não controlam os tempos de inserção e atualização em linhas individuais, o SQL Server aplica o atraso aos rowgroups delta no estado CLOSED.

O padrão é 0 minuto.

Para obter recomendações de quando usar COMPRESSION_DELAY, confira Introdução ao columnstore para análise operacional em tempo real

<table_option> ::=

Especifica uma ou mais opções de tabela.

DATA_COMPRESSION

Especifica a opção de compactação de dados para a tabela, o número de partição ou o intervalo de partições especificado. As opções são as descritas a seguir:

Nenhuma

A tabela ou as partições especificadas não são compactadas.
ROW

A tabela ou as partições especificadas são compactadas usando a compactação de linha.
PAGE

A tabela ou as partições especificadas são compactadas usando a compactação de página.
COLUMNSTORE

Aplica-se a: SQL Server 2016 (13.x) e posterior e Banco de Dados SQL do Azure.

Aplica-se somente a índices columnstore, incluindo índices columnstore não clusterizados e clusterizados. COLUMNSTORE especifica para compactar com a compactação columnstore de maior desempenho. Essa é a opção típica.
COLUMNSTORE_ARCHIVE

Aplica-se a: SQL Server 2016 (13.x) e posterior e Banco de Dados SQL do Azure.

Aplica-se somente a índices columnstore, incluindo índices columnstore não clusterizados e clusterizados. COLUMNSTORE_ARCHIVE compactará ainda mais a tabela ou a partição para um tamanho menor. Isso pode ser usado para fins de arquivamento, ou em outras situações que exijam menos armazenamento e possam dispensar mais tempo para armazenamento e recuperação.

Para saber mais, veja Data Compression.

XML_COMPRESSION

Aplicável a: SQL Server 2022 (16.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Especifica a opção de compactação XML para qualquer coluna de tipo de dados xml na tabela. As opções são as descritas a seguir:

ATIVADO

As colunas que usam o tipo de dados xml são compactadas.
OFF

As colunas que usam o tipo de dados xml não são compactadas.

ON PARTITIONS ( { <partition_number_expression> | [ ,... n ] )

Especifica as partições às quais as configurações DATA_COMPRESSION e XML_COMPRESSION se aplicam. Se a tabela não for particionada, o argumento ON PARTITIONS vai gerar um erro. Se a cláusula ON PARTITIONS não for fornecida, a opção DATA_COMPRESSION será aplicada a todas as partições de uma tabela particionada.

partition_number_expression pode ser especificado das seguintes maneiras:

Forneça o número de uma partição, por exemplo: ON PARTITIONS (2)
Forneça os números de várias partições individuais separados por vírgulas, por exemplo: ON PARTITIONS (1, 5)
Forneça os intervalos e as partições individuais, por exemplo: ON PARTITIONS (2, 4, 6 TO 8)

<range> pode ser especificado como números de partição separados pela palavra TO, por exemplo: ON PARTITIONS (6 TO 8).

Para definir tipos diferentes de compactação de dados para partições diferentes, especifique a opção DATA_COMPRESSION mais de uma vez, por exemplo:

WITH
(
    DATA_COMPRESSION = NONE ON PARTITIONS (1),
    DATA_COMPRESSION = ROW ON PARTITIONS (2, 4, 6 TO 8),
    DATA_COMPRESSION = PAGE ON PARTITIONS (3, 5)
);

Você também pode especificar a opção XML_COMPRESSION mais de uma vez, por exemplo:

WITH
(
    XML_COMPRESSION = OFF ON PARTITIONS (1),
    XML_COMPRESSION = ON ON PARTITIONS (2, 4, 6 TO 8),
    XML_COMPRESSION = OFF ON PARTITIONS (3, 5)
);

<index_option> ::=

Especifica uma ou mais opções de índice. Para obter uma descrição completa dessas opções, consulte CREATE INDEX.

PAD_INDEX = { ON | OFF }

Quando ON, a porcentagem de espaço livre especificada por FILLFACTOR será aplicada às páginas de nível intermediário do índice. Quando OFF ou se o valor de FILLFACTOR não foi especificado, as páginas de nível intermediário são preenchidas até próximo de sua capacidade, deixando espaço suficiente para pelo menos uma linha do tamanho máximo que o índice pode ter, considerando o conjunto de chaves em páginas intermediárias. O padrão é OFF.

FILLFACTOR = fillfactor

Especifica uma porcentagem que indica quanto Mecanismo de Banco de Dados deve preencher o nível folha de cada página de índice durante a criação ou alteração do índice. fillfactor deve ser um valor inteiro de 1 a 100. O padrão é 0. Os valores de fator de preenchimento 0 e 100 são iguais em todos os aspectos.

IGNORE_DUP_KEY = { ON | OFF }

Especifica a resposta de erro quando uma operação de inserção tenta inserir valores da chave duplicada em um índice exclusivo. A opção IGNORE_DUP_KEY aplica-se apenas a operações de inserção depois que o índice é criado ou recriado. A opção não tem nenhum efeito ao executar CREATE INDEX, ALTER INDEX ou UPDATE. O padrão é OFF.

ATIVADO

Uma mensagem de aviso será exibida quando valores de chave duplicados forem inseridos em um índice exclusivo. Ocorrerá falha somente nas linhas que violarem a restrição de exclusividade.
OFF

Ocorrerá uma mensagem de erro quando os valores de chave duplicados forem inseridos em um índice exclusivo. Toda a operação INSERT será revertida.

IGNORE_DUP_KEY não pode ser definido como ON para índices criados em uma exibição, índices não exclusivos, índices XML, índices espaciais e índices filtrados.

Para exibir IGNORE_DUP_KEY, use sys.indexes.

Na sintaxe compatível com versões anteriores, WITH IGNORE_DUP_KEY é equivalente a WITH IGNORE_DUP_KEY = ON.

STATISTICS_NORECOMPUTE = { ON | OFF }

Quando for definido como ON, as estatísticas de índice desatualizadas não serão recalculadas automaticamente. Quando OFF, a atualização automática de estatísticas será habilitada. O padrão é OFF.

ALLOW_ROW_LOCKS = { ON | OFF }

Quando ON, bloqueios de linha serão permitidos quando você acessar o índice. O Mecanismo de Banco de Dados determina quando os bloqueios de linha são usados. No caso de OFF, não são usados bloqueios de linha. O padrão é ON.

ALLOW_PAGE_LOCKS = { ON | OFF }

Quando ON, bloqueios de página serão permitidos quando você acessar o índice. O Mecanismo de Banco de Dados determina quando os bloqueios de página são usados. No caso de OFF, não são usados bloqueios de página. O padrão é ON.

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }

Aplica-se a: SQL Server 2019 (15.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Especifica se a contenção de inserção de última página será ou não otimizada. O padrão é OFF. Para saber mais, confira a seção Chaves sequenciais da página CREATE INDEX.

FILETABLE_DIRECTORY = directory_name

Aplica-se a: SQL Server 2012 (11.x) e posterior.

Especifica o nome do diretório FileTable compatível com Windows. Esse nome deve ser exclusivo entre todos os nomes de diretórios de FileTable no banco de dados. A comparação de exclusividade não diferencia maiúsculas de minúsculas, independentemente das configurações de ordenação. Se esse valor não for especificado, o nome de FileTable será usado.

FILETABLE_COLLATE_FILENAME = { collation_name | database_default }

Aplica-se a: SQL Server 2012 (11.x) e posterior. O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure não são compatíveis com FILETABLE.

Especifica o nome da ordenação a ser aplicado à coluna Name da FileTable. A ordenação não deve diferenciar maiúsculas de minúsculas para ser compatível com a semântica de nomenclatura de arquivos do sistema operacional Windows. Se esse valor não for especificado, a ordenação padrão do banco de dados será usada. Se a ordenação padrão do banco de dados diferenciar maiúsculas de minúsculas, será gerado um erro e a operação CREATE TABLE falhará.

collation_name

O nome de uma ordenação sem diferenciação de maiúsculas e minúsculas.
database_default

Especifica que a ordenação padrão do banco de dados deve ser usada. Esse ordenação não deve diferenciar maiúsculas de minúsculas.

FILETABLE_PRIMARY_KEY_CONSTRAINT_NAME = nome_da_restrição

Aplica-se a: SQL Server 2012 (11.x) e posterior. O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure não são compatíveis com FILETABLE.

Especifica o nome a ser usado para a restrição de chave primária que é criada automaticamente no FileTable. Se esse valor não for especificado, o sistema vai gerar um nome para a restrição.

FILETABLE_STREAMID_UNIQUE_CONSTRAINT_NAME = nome_da_restrição

Aplica-se a: SQL Server 2012 (11.x) e posterior. O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure não são compatíveis com FILETABLE.

Especifica o nome a ser usado para a restrição exclusiva criada automaticamente na coluna stream_id na FileTable. Se esse valor não for especificado, o sistema vai gerar um nome para a restrição.

FILETABLE_FULLPATH_UNIQUE_CONSTRAINT_NAME = nome_da_restrição

Aplica-se a: SQL Server 2012 (11.x) e posterior. O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure não são compatíveis com FILETABLE.

Especifica o nome a ser usado para a restrição exclusiva criada automaticamente nas colunas parent_path_locator e name na FileTable. Se esse valor não for especificado, o sistema vai gerar um nome para a restrição.

SYSTEM_VERSIONING = ON [ ( HISTORY_TABLE = schema_name.history_table_name [ , DATA_CONSISTENCY_CHECK = { ON | OFF } ] ) ]

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Habilitará o controle de versão do sistema da tabela se o tipo de dados, a restrição de nulidade e os requisitos de restrição de chave primária forem atendidos. O sistema registrará o histórico de cada registro na tabela com controle de versão do sistema em uma tabela de histórico separada. Se o argumento HISTORY_TABLE não for usado, o nome dessa tabela de histórico será MSSQL_TemporalHistoryFor<primary_table_object_id>. Se o nome de uma tabela de histórico estiver especificado durante a criação da tabela de histórico, você deverá especificar o nome do esquema e da tabela.

Se a tabela de histórico não existir, o sistema vai gerar uma nova tabela de histórico correspondente ao esquema da tabela atual no mesmo grupo de arquivos que a tabela atual, criando um link entre as duas tabelas e permitindo que o sistema registre o histórico de cada registro da tabela atual na tabela de histórico. Por padrão, a tabela de histórico é compactada por PAGE.

Se o argumento HISTORY_TABLE for usado para criar um vínculo e usar uma tabela de histórico existente, o vínculo será criado entre a tabela atual e a tabela especificada. Se a tabela atual estiver particionada, a tabela de histórico será criada no grupo de arquivo padrão porque a configuração de particionamento não será replicada automaticamente da tabela atual para a tabela de histórico. Ao criar um link para uma tabela de histórico existente, você pode optar por executar uma verificação de consistência de dados. Essa verificação de consistência de dados garante que os registros existentes não se sobreponham. A execução da verificação de consistência dos dados é o padrão.

Use esse argumento com os argumentos PERIOD FOR SYSTEM_TIME e GENERATED ALWAYS AS ROW { START | END } para habilitar o controle de versão do sistema em uma tabela. Para saber mais, veja Temporal Tables. Use esse argumento com o argumento WITH LEDGER = ON para criar uma tabela do razão atualizável. Não é permitido usar tabelas de histórico existentes com tabelas do razão.

REMOTE_DATA_ARCHIVE = { ON [ ( table_stretch_options [ ,... n ] ) ] | OFF ( MIGRATION_STATE = PAUSED ) }

Aplica-se a: SQL Server 2016 (13.x) e posterior.

Cria a nova tabela com o Stretch Database habilitado ou desabilitado. Para obter mais informações, consulte Stretch Database.

Importante

O banco de dados de ampliação foi preterido no SQL Server 2022 (16.x) e no Banco de Dados SQL do Azure. Esse recurso será removido em uma versão futura do mecanismo de banco de dados. Evite usar esse recurso em desenvolvimentos novos e planeje modificar os aplicativos que atualmente o utilizam.

Habilitar o Stretch Database para uma tabela

Quando você habilitar Stretch para uma tabela especificando ON, pode opcionalmente especificar MIGRATION_STATE = OUTBOUND para começar a migração de dados imediatamente ou MIGRATION_STATE = PAUSED para adiar a migração de dados. O valor padrão é MIGRATION_STATE = OUTBOUND. Para obter mais informações sobre como habilitar o Stretch para uma tabela, consulte Habilitar o Stretch Database para uma tabela.

Pré-requisitos. Antes de habilitar o Stretch para uma tabela, você precisa habilitar o Stretch no servidor e no banco de dados. Para obter mais informações, consulte Enable Stretch Database for a database.

Permissões. Habilitar o Stretch para um banco de dados ou uma tabela exige permissões db_owner. Habilitar o Stretch em uma tabela também requer permissões ALTER na tabela.

[ FILTER_PREDICATE = { NULL | predicate } ]

Aplica-se a: SQL Server 2016 (13.x) e posterior.

Opcionalmente, especifique um predicado de filtro para selecionar linhas para migrar de uma tabela que contém dados atuais e históricos. O predicado deve chamar uma função com valor de tabela embutido determinística. Para obter mais informações, veja Habilitar Stretch Database para uma tabela e Selecionar linhas a serem migradas usando uma função de filtro.

Importante

Se você fornecer um predicado de filtro precário, a migração de dados também será precária. O Stretch Database aplica o predicado de filtro à tabela usando o operador CROSS APPLY.

Se você não especificar um predicado de filtro, a tabela inteira será migrada.

Quando você especifica um predicado de filtro, também precisa especificar MIGRATION_STATE.

MIGRATION_STATE = { OUTBOUND | INBOUND | PAUSED }

Aplica-se a: SQL Server 2016 (13.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Especifique OUTBOUND para migrar dados do SQL Server para o Banco de Dados SQL do Azure.
Especifique INBOUND para copiar os dados remotos na tabela do Banco de Dados SQL do Azure novamente para o SQL Server e para desabilitar o Stretch na tabela. Para obter mais informações, consulte Desabilitar Stretch Database e trazer de volta dados remotos.

Essa operação incorre em custos de transferência de dados e não pode ser cancelada.
Especifique PAUSED para pausar ou adiar a migração de dados. Para obter mais informações, veja Pausar e retomar a migração de dados – Stretch Database.

[ DATA_DELETION = ON { ( FILTER_COLUMN = column_name, RETENTION_PERIOD = { INFINITE | number { DAY | DAYS | WEEK | WEEKS | MONTH | MONTHS | YEAR | YEARS } ) } ]

Aplica-se a:somente ao SQL do Azure no Edge

Habilita a limpeza baseada em política de retenção de dados antigos em tabelas de um banco de dados. Para obter mais informações, confira Habilitar e desabilitar a retenção de dados. Os parâmetros a seguir precisam ser especificados para que a retenção de dados seja habilitada.

FILTER_COLUMN = { column_name }

Especifica a coluna que deve ser usada para determinar se as linhas da tabela são obsoletas ou não. Os tipos de dados a seguir são permitidos na coluna de filtro.
- date
- datetime
- datetime2
- smalldatetime
- datetimeoffset
RETENTION_PERIOD = { INFINITE | number {DAY | DAYS | WEEK | WEEKS | MONTH | MONTHS | YEAR | YEARS }}

Especifica a política de período de retenção para a tabela. O período de retenção é especificado como uma combinação de um valor inteiro positivo e a unidade de parte de data.

MEMORY_OPTIMIZED

Aplica-se a: SQL Server 2014 (12.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure. Instância Gerenciada do Azure SQL não oferece suporte a tabelas otimizadas para memória na camada de Uso Geral.

O valor ON indica que a tabela é otimizada para memória. As tabelas com otimização de memória fazem parte do recurso OLTP in-memory, que é usado para otimização de desempenho do processamento de transações. Para começar com o OLTP in-memory, confira Início Rápido 1: tecnologias do OLTP in-memory para um desempenho mais rápido do Transact-SQL. Para obter informações mais detalhadas sobre as tabelas com otimização de memória, veja Tabelas com otimização de memória.

O valor padrão OFF indica que a tabela é baseada em disco.

DURABILITY

Aplica-se a: SQL Server 2014 (12.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

O valor de SCHEMA_AND_DATA indica que a tabela é durável, o que significa que as alterações são persistidas em disco e sobrevivem à reinicialização ou ao failover. SCHEMA_AND_DATA é o valor padrão.

O valor de SCHEMA_ONLY indica que a tabela é não durável. O esquema da tabela é mantido, mas as atualizações de dados não são mantidas após uma reinicialização ou um failover do banco de dados. DURABILITY = SCHEMA_ONLY só é permitido com MEMORY_OPTIMIZED = ON.

Aviso

Quando uma tabela é criada com DURABILITY = SCHEMA_ONLY, e READ_COMMITTED_SNAPSHOT, depois é alterada usando ALTER DATABASE, os dados na tabela serão perdidos.

BUCKET_COUNT

Aplica-se a: SQL Server 2014 (12.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Indica o número de buckets que devem ser criados no índice de hash. O valor máximo para BUCKET_COUNT em índices de hash é 1.073.741.824. Para obter mais informações sobre o número de buckets, veja Índices para tabelas com otimização de memória.

Bucket_count é um argumento obrigatório.

INDEX

Aplica-se a: SQL Server 2014 (12.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Índices de coluna e tabela podem ser especificados como parte da instrução CREATE TABLE. Para obter detalhes sobre como adicionar e remover índices em tabelas com otimização de memória, confira Alterar tabelas com otimização de memória

HASH

Aplica-se a: SQL Server 2014 (12.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Indica que um índice de HASH foi criado.

Os índices de hash têm suporte apenas em tabelas com otimização de memória.

LEDGER = ON ( <ledger_option> [ ,... n ] ) | OFF

Aplica-se a: SQL Server 2022 (16.x), Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Observação

Se a instrução criar uma tabela de razão, a permissão ENABLE LEDGER será necessária.

Indica se a tabela que está sendo criada é uma tabela do razão (ON) ou não (OFF). O padrão é OFF. Se a opção APPEND_ONLY = ON for especificada, o sistema criará uma tabela do razão somente de acréscimo que permitirá a inserção de novas linhas. Caso contrário, o sistema criará uma tabela do razão atualizável. Uma tabela do razão atualizável também exige o argumento SYSTEM_VERSIONING = ON. Uma tabela do razão atualizável também deve ser uma tabela com controle de versão do sistema. No entanto, uma tabela do razão atualizável não precisa ser uma tabela temporal (não exige o parâmetro PERIOD FOR SYSTEM_TIME). Caso a tabela de histórico seja especificada com LEDGER = ON e SYSTEM_VERSIONING = ON, ela não fará referência a uma tabela existente.

Um banco de dados do razão (um banco de dados criado com a opção LEDGER = ON) só permite a criação de tabelas do razão. Tentativas de criar uma tabela com LEDGER = OFF gerarão um erro. Por padrão, cada tabela é criada como uma tabela do razão atualizável, mesmo que você não especifique LEDGER = ON, além de ser criada com valores padrão para todos os outros parâmetros.

Uma tabela do razão atualizável precisa conter quatro colunas GENERATED ALWAYS, exatamente uma coluna definida com cada um dos seguintes argumentos:

GENERATED ALWAYS AS TRANSACTION_ID START
GENERATED ALWAYS AS TRANSACTION_ID END
GENERATED ALWAYS AS SEQUENCE_NUMBER START
GENERATED ALWAYS AS SEQUENCE_NUMBER END

Uma tabela do razão somente de acréscimo precisa conter exatamente uma coluna definida com cada um dos seguintes argumentos:

GENERATED ALWAYS AS TRANSACTION_ID START
GENERATED ALWAYS AS SEQUENCE_NUMBER START

Se uma das colunas sempre geradas obrigatórias não estiver definida na instrução CREATE TABLE e essa instrução incluir LEDGER = ON, o sistema vai tentar adicionar a coluna automaticamente usando uma definição de coluna aplicável da lista abaixo. Caso haja um conflito de nome com uma coluna já definida, o sistema vai gerar um erro.

[ledger_start_transaction_id] BIGINT GENERATED ALWAYS AS TRANSACTION_ID START HIDDEN NOT NULL
[ledger_end_transaction_id] BIGINT GENERATED ALWAYS AS TRANSACTION_ID END HIDDEN NULL
[ledger_start_sequence_number] BIGINT GENERATED ALWAYS AS SEQUENCE_NUMBER START HIDDEN NOT NULL
[ledger_end_sequence_number] BIGINT GENERATED ALWAYS AS SEQUENCE_NUMBER END HIDDEN NULL

O <ledger_view_option> especifica o esquema e o nome da exibição do razão que o sistema cria automaticamente e vincula à tabela. Se a opção não for especificada, o sistema vai gerar o nome da exibição do razão acrescentando _Ledger ao nome da tabela que está sendo criada (database_name.schema_name.table_name). Se existir uma exibição com o nome especificado ou gerado, o sistema vai gerar um erro. Se a tabela for uma tabela do razão atualizável, a exibição do razão será criada como uma união na tabela e na tabela de histórico.

Cada linha na exibição do razão representa a criação ou a exclusão de uma versão de linha na tabela do razão. A exibição do razão contém todas as colunas da tabela do razão, exceto as colunas sempre geradas listadas acima. A exibição do razão também contém as seguintes colunas adicionais:

Nome da coluna	Tipo de dados	Descrição
Especificado por meio da opção `TRANSACTION_ID_COLUMN_NAME`. `ledger_transaction_id`, se não for especificado.	BIGINT	A ID da transação que criou ou excluiu uma versão de linha.
Especificado por meio da opção `SEQUENCE_NUMBER_COLUMN_NAME`. `ledger_sequence_number`, se não for especificado.	BIGINT	O número de sequência de uma operação em nível de linha dentro da transação na tabela.
Especificado por meio da opção `OPERATION_TYPE_COLUMN_NAME`. `ledger_operation_type`, se não for especificado.	TINYINT	Contém `1` (`INSERT`) ou `2` (`DELETE`). A inserção de uma linha na tabela do razão produz uma nova linha na exibição do razão que contém `1` nessa coluna. A exclusão de uma linha da tabela do razão produz uma nova linha na exibição do razão que contém `2` nessa coluna. A atualização de uma linha na tabela do razão produz duas novas linhas na exibição do razão. Uma linha contém `2` (`DELETE`) e a outra contém `1` (`INSERT`) nessa coluna.
Especificado por meio da opção `OPERATION_TYPE_DESC_COLUMN_NAME`. `ledger_operation_type_desc`, se não for especificado.	nvarchar(128)	Contém `INSERT` ou `DELETE`. Veja acima para obter detalhes.

As transações que incluem a criação da tabela do razão são capturadas em sys.database_ledger_transactions.

<ledger_option> ::=

Especifica uma opção do razão.

[ LEDGER_VIEW = schema_name.ledger_view_name [ ( <ledger_view_option> [ ,... n ] ) ]

Especifica o nome da exibição do razão e os nomes de colunas adicionais que o sistema adiciona à exibição do razão.

[ APPEND_ONLY = ON | OFF ]

Especifica se a tabela do razão que está sendo criada é somente acréscimo ou atualizável. O padrão é OFF.

<ledger_view_option> ::=

Especifica uma ou mais opções de exibição do razão. Cada opção de exibição do razão especifica um nome de uma coluna que o sistema adicionará à exibição, além das colunas definidas na tabela do razão.

[ TRANSACTION_ID_COLUMN_NAME = transaction_id_column_name ]

Especifica o nome da coluna que armazena a ID da transação que criou ou excluiu uma versão de linha. O nome da coluna padrão é ledger_transaction_id.

[ SEQUENCE_NUMBER_COLUMN_NAME = sequence_number_column_name ]

Especifica o nome das colunas que armazenam o número de sequência de uma operação em nível de linha dentro da transação na tabela. O nome da coluna padrão é ledger_sequence_number.

[ OPERATION_TYPE_COLUMN_NAME = operation_type_id column_name ]

Especifica o nome das colunas que armazenam a ID do tipo de operação. O nome da coluna padrão é ledger_operation_type.

[ OPERATION_TYPE_DESC_COLUMN_NAME = operation_type_desc_column_name ]

Especifica o nome das colunas que armazenam a descrição do tipo de operação. O nome da coluna padrão é ledger_operation_type_desc.

Comentários

Para obter informações sobre o número de tabelas, colunas, restrições e índices permitidos, veja Especificações de capacidade máxima para o SQL Server.

Geralmente, o espaço é alocado a tabelas e índices em incrementos de uma extensão por vez. Quando a opção SET MIXED_PAGE_ALLOCATION de ALTER DATABASE é definida como TRUE ou sempre antes de SQL Server 2016 (13.x), quando uma tabela ou um índice é criado, são alocadas páginas de extensões mistas até que haja páginas suficientes para preencher uma extensão uniforme. Quando houver páginas suficiente para preencher um extensão uniforme, outra extensão será alocada sempre que as extensões já alocadas ficarem cheias. Para um obter um relatório sobre a quantidade de espaço alocado e usado por uma tabela, execute sp_spaceused.

O Mecanismo de Banco de Dados não impõe uma ordem para especificar DEFAULT, IDENTITY, ROWGUIDCOL ou restrições de coluna em uma definição de coluna.

Quando uma tabela é criada, a opção QUOTED IDENTIFIER sempre é armazenada como ON nos metadados da tabela, mesmo que a opção esteja definida como OFF quando a tabela é criada.

No banco de dados SQL no Microsoft Fabric, alguns recursos de tabela podem ser criados, mas não serão espelhados no Fabric OneLake. Para obter mais informações, consulte Limitações do espelhamento de banco de dados SQL do Fabric.

Tabelas temporárias

Você pode criar tabelas temporárias locais e globais. Tabelas temporárias locais são visíveis apenas na sessão atual e tabelas temporárias globais são visíveis em todas as sessões. Não é possível particionar tabelas temporárias.

Inclua um prefixo nos nomes de tabelas temporárias locais com uma só tecla jogo da velha (#table_name) e os de tabelas temporárias globais com duas teclas jogo da velha (##table_name).

As instruções Transact-SQL referenciam a tabela temporária usando o valor especificado para table_name na instrução CREATE TABLE, por exemplo:

CREATE TABLE #MyTempTable (
    col1 INT PRIMARY KEY
);

INSERT INTO #MyTempTable
VALUES (1);

Se mais de uma tabela temporária for criada em um procedimento armazenado ou lote, elas devem ter nomes diferentes.

Se você incluir um schema_name quando criar ou acessar uma tabela temporária, ele será ignorado. Todas as tabelas temporárias são criadas no esquema dbo.

Se uma tabela temporária local for criada em um procedimento armazenado ou aplicativo que possa ser executado ao mesmo tempo por várias sessões, o Mecanismo de Banco de Dados deverá conseguir distinguir as tabelas criadas pelas diferentes sessões. O Mecanismo de Banco de Dados faz isso acrescentando internamente um sufixo numérico a cada nome de tabela temporária local. O nome completo de uma tabela temporária como ele foi armazenado na tabela sys.sysobjects em tempdb é composto pelo nome da tabela especificado na instrução CREATE TABLE e o sufixo numérico gerado pelo sistema. Para permitir o sufixo, o table_name especificado para um nome temporário local não pode exceder 116 caracteres.

As tabelas temporárias serão descartadas automaticamente se não se ultrapassarem o escopo, a menos que sejam explicitamente descartadas com o uso de DROP TABLE:

Uma tabela temporária local criada em um procedimento armazenado será descartada automaticamente quando o procedimento armazenado for encerrado. A tabela pode ser referenciada por qualquer procedimento armazenado aninhado executado pelo procedimento armazenado que criou a tabela. A tabela não pode ser referenciada pelo processo que chamou o procedimento armazenado que a criou.
Todas as outras tabelas temporárias locais serão descartadas automaticamente ao término da sessão atual.
As tabelas temporárias globais serão descartadas automaticamente ao término da sessão que criou e quando todas as demais tarefas pararem de fazer referência a ela. A associação entre uma tarefa e uma tabela será mantida apenas enquanto durar uma única instrução Transact-SQL. Ou seja, a tabela temporária global será descartada ao término da última instrução Transact-SQL que estava referenciando ativamente a tabela ao término da sessão de criação.

Uma tabela temporária local criada em um procedimento armazenado ou gatilho pode ter o mesmo nome de uma tabela temporária que foi criada antes de o procedimento armazenado ou gatilho ser chamado. Contudo, se uma consulta fizer referência a uma tabela temporária e houver duas tabelas temporárias com o mesmo nome, não haverá definição de qual tabela servirá de base para a consulta. Procedimentos armazenados aninhados também podem criar tabelas temporárias com o mesmo nome de uma tabela temporária que foi criada pelo procedimento armazenado que o chamou. Entretanto, para que modificações sejam resolvidas na tabela que foi criada no procedimento aninhado, a tabela deve ter a mesma estrutura, com os mesmos nomes de colunas, da tabela criada pelo procedimento que o chamou. Isso é mostrado no exemplo a seguir.

CREATE PROCEDURE dbo.Test2
AS
    CREATE TABLE #t (x INT PRIMARY KEY);
    INSERT INTO #t VALUES (2);
    SELECT Test2Col = x FROM #t;
GO

CREATE PROCEDURE dbo.Test1
AS
    CREATE TABLE #t (x INT PRIMARY KEY);
    INSERT INTO #t VALUES (1);
    SELECT Test1Col = x FROM #t;
    EXEC Test2;
GO

CREATE TABLE #t(x INT PRIMARY KEY);
INSERT INTO #t VALUES (99);
GO

EXEC Test1;
GO

Veja a seguir o conjunto de resultados.

(1 row(s) affected)
Test1Col
-----------
1

(1 row(s) affected)
 Test2Col
 -----------
 2

Quando você cria tabelas temporárias locais ou globais, a sintaxe CREATE TABLE dá suporte a definições de restrição, exceto para restrições FOREIGN KEY. Se for especificada uma restrição FOREIGN KEY em uma tabela temporária, a instrução retornará uma mensagem de aviso informando que a restrição foi ignorada. A tabela ainda será criada sem as restrições FOREIGN KEY. Tabelas temporárias não podem ser referenciadas em restrições FOREIGN KEY.

Se uma tabela temporária for criada com uma restrição nomeada e se for criada dentro do escopo de uma transação definida pelo usuário, somente um usuário de cada vez poderá executar a instrução que cria a tabela temporária. Por exemplo, se um procedimento armazenado criar uma tabela temporária com uma restrição de chave primária nomeada, o procedimento armazenado não poderá ser executado simultaneamente por vários usuários.

Tabelas temporárias globais no escopo do banco de dados (Banco de Dados SQL do Azure)

As tabelas temporárias globais do SQL Server (iniciadas com ## e depois o nome de tabela) são armazenadas em tempdb e compartilhadas entre as sessões de todos os usuários em toda a instância do SQL Server. Para obter informações sobre tipos de tabela SQL, veja a seção acima em Criar tabelas.

O Banco de Dados SQL do Azure é compatível com tabelas temporárias globais que também são armazenadas em tempdb e têm o escopo definido para o nível do banco de dados. Isso significa que as tabelas temporárias globais são compartilhadas para as sessões de todos os usuários no mesmo Banco de Dados SQL do Azure. As sessões de usuário de outros bancos de dados não podem acessar tabelas temporárias globais.

Tabelas temporárias globais para o Banco de Dados SQL do Azure seguem a mesma sintaxe e a mesma semântica que o SQL Server usa para tabelas temporárias. De modo similar, os procedimentos armazenados temporários globais também têm o escopo definido para o nível do Banco de Dados SQL do Azure. Tabelas temporárias locais (iniciadas com # nome da tabela) também são compatíveis com o Banco de Dados SQL do Azure e seguem a mesma sintaxe e a mesma semântica que o SQL Server usa. Veja a seção acima em Tabelas temporárias.

Importante

Este recurso está disponível no Banco de Dados SQL do Azure.

Solução de problemas de tabelas temporárias globais para o Banco de Dados SQL do Azure

Para solucionar problemas de tempdb, confira Como monitorar o uso de tempdb.

Observação

Somente um administrador de servidor pode acessar as DMVs de solução de problemas em Banco de Dados SQL do Azure.

Permissões para objetos temporários

Qualquer usuário pode criar objetos temporários globais. Os usuários podem acessar somente seus próprios objetos, a menos que recebam permissões adicionais.

Tabelas particionadas

Antes de criar uma tabela particionada usando CREATE TABLE, crie uma função de partição para especificar como a tabela será particionada. Uma função de partição é criada usando CREATE PARTITION FUNCTION. Em seguida, crie um esquema de partição para especificar os grupos de arquivos que manterão as partições indicadas pela função de partição. Um esquema de partição é criado usando CREATE PARTITION SCHEME. O uso das restrições PRIMARY KEY ou UNIQUE para separar grupos de arquivos não pode ser especificado para tabelas particionadas. Para saber mais, confira Partitioned Tables and Indexes.

restrições PRIMARY KEY

Uma tabela pode conter apenas uma restrição PRIMARY KEY.
O índice gerado pela restrição PRIMARY KEY não pode fazer com que o número de índices na tabela exceda 999 índices não clusterizados e 1 índice clusterizado.
Se CLUSTERED ou NONCLUSTERED não estiver especificado para uma restrição PRIMARY KEY, CLUSTERED será usado se não houver índices clusterizados especificados para restrições UNIQUE.
Todas as colunas definidas em uma restrição PRIMARY KEY devem ser definidas como NOT NULL. Se a nulidade não for especificada, todas as colunas participantes de uma restrição FOREIGN KEY deverão ter a nulidade definida como NOT NULL.

Observação

Para tabelas com otimização de memória, a coluna de chave anulável é permitida.
Se a chave primária for definida em uma coluna de tipo CLR definida pelo usuário, a implementação do tipo deverá oferecer suporte a uma ordenação binária. Para obter mais informações, veja Tipos CLR definidos pelo usuário.

Restrições UNIQUE

Se não for especificado CLUSTERED nem NONCLUSTERED para uma restrição UNIQUE, NONCLUSTERED será usado por padrão.
Cada restrição UNIQUE gera um índice. O número de restrições UNIQUE não pode fazer com que o número de índices na tabela exceda 999 índices não clusterizados e 1 índice clusterizado.
Se a restrição unique for definida em uma coluna de tipo de dados CLR definido pelo usuário, a implementação do tipo deverá oferecer suporte a uma ordenação binária ou com base no operador. Para obter mais informações, veja Tipos CLR definidos pelo usuário.

Restrições FOREIGN KEY

Quando um valor diferente de NULL é inserido na coluna de uma restrição FOREIGN KEY, o valor deve existir na coluna referenciada; caso contrário, será retornada uma mensagem de erro de violação de chave estrangeira.
Restrições FOREIGN KEY serão aplicadas à coluna precedente, a menos que sejam especificadas colunas de origem.
As restrições FOREIGN KEY só podem fazer referência a tabelas que estão no mesmo banco de dados e no mesmo servidor. A integridade referencial em todos os bancos de dados deve ser implementada por gatilhos. Para mais informações, veja CREATE TRIGGER.
As restrições FOREIGN KEY podem fazer referência a outra coluna da mesma tabela. Isso se chama autorreferência.
A cláusula REFERENCES de uma restrição FOREIGN KEY no nível de coluna pode listar apenas uma coluna de referência. Essa coluna deve ter o mesmo tipo de dados da coluna na qual a restrição foi definida.
O número de colunas de referência da cláusula REFERENCES de uma restrição FOREIGN KEY deve ser igual ao número de colunas da lista de colunas de restrição. O tipo de dados de cada coluna de referência também deve ser igual ao da coluna correspondente na lista de colunas. As colunas de referência devem ser especificadas na mesma ordem que foi usada ao especificar as colunas da chave primária ou restrição exclusiva na tabela referenciada.
CASCADE, SET NULL ou SET DEFAULT não poderão ser especificados se uma coluna do tipo timestamp fizer parte da chave estrangeira ou da chave referenciada.
CASCADE, SET NULL, SET DEFAULT e NO ACTION podem ser combinados nas tabelas que tenham relacionamentos referenciais entre si. Se o Mecanismo de Banco de Dados encontrar NO ACTION, parará e reverterá as ações CASCATA, SET NULL e SET DEFAULT. Quando uma instrução DELETE provoca uma combinação de ações CASCADE, SET NULL, SET DEFAULT e NO ACTION, todas as ações CASCADE, SET NULL e SET DEFAULT são aplicadas antes que o Mecanismo de Banco de Dados verifique se existe alguma NO ACTION.
O Mecanismo de Banco de Dados não tem um limite predefinido quanto ao número de restrições FOREIGN KEY que uma tabela pode conter para referenciar outras tabelas nem quanto ao número de restrições FOREIGN KEY que pertencem a outras tabelas que fazem referência a uma tabela específica.

Entretanto, o número real de restrições FOREIGN KEY que pode ser usado é limitado pela configuração do hardware e pelo design do banco de dados e do aplicativo. Recomendamos que uma tabela não contenha mais de 253 restrições FOREIGN KEY e que ela não seja referenciada por mais de 253 restrições FOREIGN KEY. O limite real pode depender mais ou menos do aplicativo e do hardware. Considere o custo da imposição de restrições FOREIGN KEY ao criar o banco de dados e os aplicativos.
As restrições FOREIGN KEY não são impostas a tabelas temporárias.
As restrições FOREIGN KEY podem fazer referência somente a colunas em restrições PRIMARY KEY ou UNIQUE na tabela ou em uma UNIQUE INDEX na tabela referenciada.
Se a chave estrangeira for definida em uma coluna de tipo de dados CLR definido pelo usuário, a implementação do tipo deverá oferecer suporte a uma ordenação binária. Para obter mais informações, veja Tipos CLR definidos pelo usuário.
As colunas que participam de uma relação de chave estrangeira devem ser definidas com o mesmo comprimento e a mesma escala.

definições DEFAULT

Uma coluna pode ter apenas uma definição DEFAULT.

Uma definição DEFAULT pode conter valores constantes, funções, funções niladic SQL padrão ou NULL. A tabela a seguir mostra as funções niladic e os valores que elas retornam para o padrão durante uma instrução INSERT.

funções niladic SQL-92	Valor retornado
CURRENT_TIMESTAMP	Data e hora atuais.
CURRENT_USER	Nome de usuário que está executando uma inserção.
SESSION_USER	Nome de usuário que está executando uma inserção.
SYSTEM_USER	Nome de usuário que está executando uma inserção.
USER	Nome de usuário que está executando uma inserção.

constant_expression em uma definição DEFAULT não pode fazer referência a uma outra coluna da tabela nem a outras tabelas, exibições ou procedimentos armazenados.
Não é possível criar definições DEFAULT em colunas com um tipo de dados timestamp nem em colunas com uma propriedade IDENTITY.
Não é possível criar definições DEFAULT para colunas com tipos de dados de alias quando o tipo de dados de alias está associado a um objeto padrão.

Restrições CHECK

Uma coluna pode ter qualquer número de restrições CHECK e os critérios podem incluir diversas expressões lógicas combinadas com AND e OR. Várias restrições CHECK são validadas na ordem de criação.
O critério de pesquisa precisa ser avaliado como uma expressão booliana e não pode fazer referência a outra tabela.
A restrição CHECK no nível de coluna pode fazer referência somente à coluna restrita, e a restrição CHECK no nível de tabela pode fazer referência somente às colunas da mesma tabela.

CHECK CONSTRAINTS e regras oferecem a mesma função de validação dos dados durante instruções INSERT e UPDATE.
Se existirem uma regra e uma ou mais restrições CHECK para uma coluna, ou colunas, todas as restrições serão avaliadas.
Restrições CHECK não podem ser definidas em colunas text, ntext ou image.

Mais informações de restrição

Um índice criado para uma restrição não pode ser removido usando DROP INDEX. A restrição precisa ser removida usando ALTER TABLE. Um índice criado para uma restrição e usado por ela pode ser reconstruído com o uso de ALTER INDEX ... REBUILD. Para obter mais informações, veja Reorganizar e recriar índices.
Os nomes de restrição precisam seguir as regras de identificadores, a não ser que o nome não possa começar com uma tecla jogo da velha (#). Se constraint_name não for fornecido, um nome gerado pelo sistema será atribuído à restrição. O nome da restrição aparece em qualquer mensagem de erro sobre violações de restrição.
Quando uma restrição é violada em uma instrução INSERT, UPDATE ou DELETE, a instrução é encerrada. No entanto, quando SET XACT_ABORT é definido como OFF, a transação continuará sendo processada, se a instrução fizer parte de uma transação explícita. Quando SET XACT_ABORT é definido como ON, a transação inteira é revertida. Use também a instrução ROLLBACK TRANSACTION com a definição de transação verificando a função do sistema @@ERROR.
Quando ALLOW_ROW_LOCKS = ON e ALLOW_PAGE_LOCK = ON, row-, page- e os bloqueios em nível de linha, página e tabela são permitidos quando você acessa o índice. O Mecanismo de Banco de Dados escolhe o bloqueio apropriado e pode escalar o bloqueio de uma linha ou página para um bloqueio de tabela. Quando ALLOW_ROW_LOCKS = OFF e ALLOW_PAGE_LOCK = OFF, o bloqueio em nível de tabela é permitido quando você acessa o índice.
Se uma tabela tiver restrições FOREIGN KEY ou CHECK e gatilhos, os critérios da restrição serão avaliados antes da execução do gatilho.

Para obter um relatório em uma tabela e suas colunas, use sp_help ou sp_helpconstraint. Para renomear uma tabela, use sp_rename. Para obter um relatório de exibições e procedimentos armazenados que dependem de uma tabela, use sys.dm_sql_referenced_entities e sys.dm_sql_referencing_entities.

Regras de nulidade em uma definição de tabela

A nulidade de uma coluna determina se ela permite ser preenchida com um valor nulo (NULL). NULL não é zero nem valor em branco: NULL significa que nenhuma entrada foi feita ou que um NULL explícito foi fornecido e, normalmente, implica que o valor é desconhecido ou não se aplica.

Quando você usa CREATE TABLE ou ALTER TABLE para criar ou alterar uma tabela, as configurações de banco de dados e de sessão influenciam e, possivelmente, substituem a nulidade do tipo de dados que é usado em uma definição de coluna. Recomendamos que você sempre defina explicitamente uma coluna como NULL ou NOT NULL para colunas não computadas ou, se usar um tipo de dados definido pelo usuário, permita que a coluna use a nulidade padrão do tipo de dados. Colunas esparsas sempre têm que permitir NULL.

Quando a nulidade da coluna não é especificada explicitamente, ela segue as regras mostradas na tabela a seguir.

Tipo de dados de coluna	Regra
Tipo de dados de alias	O Mecanismo de Banco de Dados usa a nulidade especificada durante a criação do tipo de dados. Para determinar a nulidade padrão do tipo de dados, use `sp_help`.
tipo de dados CLR definido pelo usuário	A nulidade é determinada de acordo com a definição de coluna.
Tipo de dados fornecido pelo sistema	Se o tipo de dados fornecido pelo sistema tiver apenas uma opção, ele prevalece. Tipos de dados timestamp devem ser tipos de dados NOT NULL. Quando uma configuração de sessão é definida como ON usando `SET`: `ANSI_NULL_DFLT_ON = ON`, NULL é atribuído. `ANSI_NULL_DFLT_OFF = ON`, NOT NULL é atribuído. Quando uma configuração de banco de dados é definida usando `ALTER DATABASE`: `ANSI_NULL_DEFAULT_ON = ON`, NULL é atribuído. `ANSI_NULL_DEFAULT_OFF = ON`, NOT NULL é atribuído. Para ver a configuração de banco de dados de `ANSI_NULL_DEFAULT`, use a exibição de catálogo `sys.databases`

Quando nenhuma das opções ANSI_NULL_DFLT estiver definida para a sessão e o banco de dados estiver configurado com o padrão (ANSI_NULL_DEFAULT é OFF), o padrão de NOT NULL será atribuído.

Se a coluna for uma coluna computada, seu nulidade sempre será determinada automaticamente pelo Mecanismo de Banco de Dados. Para descobrir a nulidade desse tipo de coluna, use a função COLUMNPROPERTY com a propriedade AllowsNull.

Observação

O driver ODBC e o driver OLE DB do SQL Server usam como padrão ANSI_NULL_DFLT_ON definido como ON. Os usuários de ODBC and OLE DB podem configurar essa opção nas fontes de dados ODBC ou usando os atributos ou as propriedades de conexão definidas pelo aplicativo.

Compactação de dados

Não é possível habilitar as tabelas do sistema para compactação. Quando você cria uma tabela, a compactação de dados é definida como NONE, a menos que especificada de outra maneira. Se for especificada uma lista de partições ou uma partição fora do intervalo, um erro será gerado. Para obter mais informações sobre compactação de dados, veja Compactação de dados.

Para avaliar como a alteração do estado de compactação afetará uma tabela, um índice ou uma partição, use o procedimento armazenado sp_estimate_data_compression_savings .

Permissões

Exige a permissão CREATE TABLE no banco de dados e a permissão ALTER no esquema no qual a tabela está sendo criada.

Se uma coluna da instrução CREATE TABLE for definida como um tipo definido pelo usuário, a permissão REFERENCES no tipo definido pelo usuário será necessária.

Se uma coluna da instrução CREATE TABLE for definida como um tipo de dados CLR definido pelo usuário, a propriedade do tipo ou a permissão REFERENCES será necessária.

Se uma coluna da instrução CREATE TABLE tiver uma coleção de esquemas XML associada a ela, a propriedade da coleção de esquemas XML ou a permissão REFERENCES será necessária.

Qualquer usuário pode criar tabelas temporárias em tempdb.

Se a instrução criar uma tabela do razão, a permissão ENABLE LEDGER será necessária.

Exemplos

a. Criar uma restrição PRIMARY KEY em uma coluna

O exemplo a seguir mostra a definição de coluna para uma restrição PRIMARY KEY com um índice clusterizado na coluna EmployeeID da tabela Employee. Como não foi especificado um nome de restrição, o sistema fornece o nome da restrição.

CREATE TABLE dbo.Employee (
    EmployeeID INT PRIMARY KEY CLUSTERED
);

B. Usar restrições FOREIGN KEY

Uma restrição FOREIGN KEY é usada para fazer referência a outra tabela. Chaves estrangeiras podem ser chaves de coluna única ou chaves de várias colunas. O próximo exemplo mostra uma restrição FOREIGN KEY de coluna única na tabela SalesOrderHeader que faz referência à tabela SalesPerson. Somente a cláusula REFERENCES é necessária para uma restrição FOREIGN KEY de coluna única.

SalesPersonID INT NULL REFERENCES SalesPerson(SalesPersonID)

Também é possível usar explicitamente a cláusula FOREIGN KEY e declarar novamente o atributo de coluna. Observe que o nome da coluna não tem que ser o mesmo nas duas tabelas.

FOREIGN KEY (SalesPersonID) REFERENCES SalesPerson(SalesPersonID)

As restrições de chaves de várias colunas são criadas como restrições de tabela. No banco de dados AdventureWorks2022, a tabela SpecialOfferProduct contém uma PRIMARY KEY de várias colunas. O exemplo a seguir mostra como fazer referência a essa chave a partir de outra tabela; um nome de restrição explícito é opcional.

CONSTRAINT FK_SpecialOfferProduct_SalesOrderDetail
    FOREIGN KEY (ProductID, SpecialOfferID)
    REFERENCES SpecialOfferProduct (ProductID, SpecialOfferID)

C. Usar restrições UNIQUE

As restrições UNIQUE são usadas para impor exclusividade a colunas de chave não primária. O exemplo a seguir impõe uma restrição indicando que a coluna Name da tabela Product deve ser exclusiva.

Name NVARCHAR(100) NOT NULL
UNIQUE NONCLUSTERED

D. Usar definições DEFAULT

Os padrões fornecem um valor (com as instruções INSERT e UPDATE) quando nenhum valor é fornecido. Por exemplo, o banco de dados AdventureWorks2022 poderia conter uma tabela de pesquisa listando os diversos cargos que os funcionários podem ocupar na empresa. Na coluna que descreve cada trabalho, uma cadeia de caracteres padrão pode fornecer uma descrição quando uma descrição real não é inserida explicitamente.

DEFAULT 'New Position - title not formalized yet'

Além de constantes, definições DEFAULT podem incluir funções. Use o exemplo a seguir para obter a data atual para uma entrada.

DEFAULT (GETDATE())

Um exame da função niladic também pode melhorar a integridade dos dados. Para monitorar o usuário que inseriu uma linha, use a função niladic para USER. Não coloque as funções niladic entre parênteses.

DEFAULT USER

E. Usar restrições CHECK

O exemplo a seguir mostra uma restrição composta pelos valores inseridos na coluna CreditRating da tabela Vendor. A restrição não é nomeada.

CHECK (CreditRating >= 1 and CreditRating <= 5)

Este exemplo mostra uma restrição nomeada com um padrão de restrição nos dados de caracteres inseridos em uma coluna de uma tabela.

CONSTRAINT CK_emp_id CHECK (
    emp_id LIKE '[A-Z][A-Z][A-Z][1-9][0-9][0-9][0-9][0-9][FM]'
    OR emp_id LIKE '[A-Z]-[A-Z][1-9][0-9][0-9][0-9][0-9][FM]'
)

Este exemplo especifica que os valores devem estar em uma lista específica ou seguir o padrão especificado.

CHECK (
    emp_id IN ('1389', '0736', '0877', '1622', '1756')
    OR emp_id LIKE '99[0-9][0-9]'
)

F. Mostrar a definição de tabela completa

O próximo exemplo mostra as definições de tabela completas com todas as definições de restrição para a tabela PurchaseOrderDetail, criada no banco de dados AdventureWorks2022. Para executar o exemplo, o esquema de tabela foi alterado para dbo.

CREATE TABLE dbo.PurchaseOrderDetail
(
    PurchaseOrderID int NOT NULL
        REFERENCES Purchasing.PurchaseOrderHeader(PurchaseOrderID),
    LineNumber smallint NOT NULL,
    ProductID int NULL
        REFERENCES Production.Product(ProductID),
    UnitPrice money NULL,
    OrderQty smallint NULL,
    ReceivedQty float NULL,
    RejectedQty float NULL,
    DueDate datetime NULL,
    rowguid uniqueidentifier ROWGUIDCOL NOT NULL
        CONSTRAINT DF_PurchaseOrderDetail_rowguid DEFAULT (NEWID()),
    ModifiedDate datetime NOT NULL
        CONSTRAINT DF_PurchaseOrderDetail_ModifiedDate DEFAULT (GETDATE()),
    LineTotal AS ((UnitPrice*OrderQty)),
    StockedQty AS ((ReceivedQty-RejectedQty)),
    CONSTRAINT PK_PurchaseOrderDetail_PurchaseOrderID_LineNumber
               PRIMARY KEY CLUSTERED (PurchaseOrderID, LineNumber)
               WITH (IGNORE_DUP_KEY = OFF)
)
ON [PRIMARY];

G. Criar uma tabela com uma coluna XML tipada como uma coleção de esquemas XML

O exemplo seguinte cria uma tabela com uma coluna xml que é digitada para a coleção de esquemas XML HRResumeSchemaCollection. A palavra-chave DOCUMENT especifica que cada instância do tipo de dados xml em column_name pode conter apenas um elemento de nível superior.

CREATE TABLE HumanResources.EmployeeResumes
(
    LName nvarchar(25),
    FName nvarchar(25),
    Resume xml(DOCUMENT HumanResources.HRResumeSchemaCollection)
);

H. Criar uma tabela particionada

O exemplo a seguir cria uma função de partição para dividir uma tabela ou índice em quatro partições. Em seguida, o exemplo cria um esquema de partição que especifica os grupos de arquivos que conterão cada uma das quatro partições. Finalmente, o exemplo cria uma tabela que usa o esquema de partição. Este exemplo supõe que os grupos de arquivos já existam no banco de dados.

CREATE PARTITION FUNCTION myRangePF1 (int)
    AS RANGE LEFT FOR VALUES (1, 100, 1000);
GO

CREATE PARTITION SCHEME myRangePS1
    AS PARTITION myRangePF1
    TO (test1fg, test2fg, test3fg, test4fg);
GO

CREATE TABLE PartitionTable (col1 int, col2 char(10))
    ON myRangePS1 (col1);
GO

Com base nos valores da coluna col1 de PartitionTable, as partições são atribuídas das seguintes maneiras.

Grupo de arquivos	test1fg	test2fg	test3fg	test4fg
Partição	1	2	3	4
Valores	`col 1 <= 1`	`col1 > 1 AND col1 <= 100`	`col1 > 100 AND col1 <= 1,000`	`col1 > 1000`

I. Usar o tipo de dados UNIQUEIDENTIFIER em uma coluna

O exemplo a seguir cria uma tabela com uma coluna uniqueidentifier. O exemplo usa uma restrição PRIMARY KEY para proteger a tabela, evitando que os usuários insiram valores duplicados, e usa a função NEWSEQUENTIALID() da restrição DEFAULT para fornecer valores para novas linhas. A propriedade ROWGUIDCOL é aplicada à coluna uniqueidentifier de forma que ela possa ser referenciada pela palavra-chave $ROWGUID.

CREATE TABLE dbo.Globally_Unique_Data
(
    GUID UNIQUEIDENTIFIER
        CONSTRAINT Guid_Default DEFAULT
        NEWSEQUENTIALID() ROWGUIDCOL,
    Employee_Name VARCHAR(60)
    CONSTRAINT Guid_PK PRIMARY KEY (GUID)
);

J. Usar uma expressão para uma coluna computada

O exemplo a seguir mostra o uso de uma expressão ((low + high)/2) para calcular a coluna computada myavg.

CREATE TABLE dbo.mytable
(
    low INT,
    high INT,
    myavg AS (low + high)/2
);

K. Criar uma coluna computada com base em uma coluna de tipo de dados definido pelo usuário

O exemplo a seguir cria uma tabela com uma coluna definida como tipo de dados definido pelo usuário utf8string, supondo que o assembly do tipo, e o próprio tipo, já foram criados no banco de dados atual. Uma segunda coluna é definida com base em utf8string, e usa o método ToString() de type(class) utf8string para calcular um valor para a coluna.

CREATE TABLE UDTypeTable
(
    u UTF8STRING,
    ustr AS u.ToString() PERSISTED
);

L. Usar uma função USER_NAME para uma coluna computada

O exemplo a seguir usa a função USER_NAME() na coluna myuser_name.

CREATE TABLE dbo.mylogintable
(
    date_in DATETIME,
    user_id INT,
    myuser_name AS USER_NAME()
);

M. Criar uma tabela com uma coluna FILESTREAM

O exemplo a seguir cria uma tabela com uma coluna FILESTREAMPhoto. Se uma tabela tiver uma ou mais colunas FILESTREAM, ela deve ter uma coluna ROWGUIDCOL.

CREATE TABLE dbo.EmployeePhoto
(
    EmployeeId INT NOT NULL PRIMARY KEY,
    Photo VARBINARY(MAX) FILESTREAM NULL,
    MyRowGuidColumn UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL UNIQUE DEFAULT NEWID()
);

N. Criar uma tabela que usa a compactação de linha

O exemplo a seguir cria uma tabela que usa compactação de linha.

CREATE TABLE dbo.T1
(
    c1 INT,
    c2 NVARCHAR(200)
)
WITH (DATA_COMPRESSION = ROW);

Para obter exemplos de compactação de dados adicionais, consulte Compactação de dados.

O. Criar uma tabela que usa a compactação XML

Aplicável a: SQL Server 2022 (16.x) e versões posteriores, Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

O exemplo a seguir cria uma tabela que usa compactação de XML.

CREATE TABLE dbo.T1
(
    c1 INT,
    c2 XML
)
WITH (XML_COMPRESSION = ON);

P. Criar uma tabela com colunas esparsas e um conjunto de colunas

Os exemplos a seguir mostram como criar uma tabela com uma coluna esparsa e uma coluna com duas colunas esparsas e um conjunto de colunas. Os exemplos usam a sintaxe básica. Para obter exemplos mais complexos, veja Usar colunas esparsas e Usar conjuntos de colunas.

Este exemplo cria uma tabela com uma coluna esparsa.

CREATE TABLE dbo.T1
(
    c1 INT PRIMARY KEY,
    c2 VARCHAR(50) SPARSE NULL
);

Este exemplo cria uma tabela com duas colunas esparsas e um conjunto de colunas nomeado CSet.

CREATE TABLE T1
(
    c1 INT PRIMARY KEY,
    c2 VARCHAR(50) SPARSE NULL,
    c3 INT SPARSE NULL,
    CSet XML COLUMN_SET FOR ALL_SPARSE_COLUMNS
);

Q. Criar uma tabela temporal baseada em disco com controle de versão do sistema

Aplica-se a: SQL Server 2016 (13.x) e posterior e Banco de Dados SQL do Azure.

Os exemplos a seguir mostram como criar uma tabela temporal vinculada a uma nova tabela de histórico e como criar uma tabela temporal vinculada a uma tabela de histórico existente. A tabela temporal precisa ter uma chave primária definida como habilitada para a tabela a ser habilitada para o controle de versão do sistema. Para obter exemplos mostrando como adicionar ou remover o controle de versão do sistema em uma tabela existente, veja controle de versão do sistema em Exemplos. Para casos de uso, veja Tabelas temporais.

Este exemplo cria uma nova tabela temporal vinculada a uma nova tabela de histórico.

CREATE TABLE Department
(
    DepartmentNumber CHAR(10) NOT NULL PRIMARY KEY CLUSTERED,
    DepartmentName VARCHAR(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber CHAR(10) NULL,
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON);

Este exemplo cria uma nova tabela temporal vinculada a uma tabela de histórico existente.

-- Existing table
CREATE TABLE Department_History
(
    DepartmentNumber CHAR(10) NOT NULL,
    DepartmentName VARCHAR(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber CHAR(10) NULL,
    ValidFrom DATETIME2 NOT NULL,
    ValidTo DATETIME2 NOT NULL
);

-- Temporal table
CREATE TABLE Department
(
    DepartmentNumber CHAR(10) NOT NULL PRIMARY KEY CLUSTERED,
    DepartmentName VARCHAR(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber CHAR(10) NULL,
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Department_History, DATA_CONSISTENCY_CHECK = ON));

R. Criar uma tabela temporal com otimização de memória e controle de versão do sistema

Aplica-se a: SQL Server 2016 (13.x) e posterior e Banco de Dados SQL do Azure.

O exemplo a seguir mostra como criar uma versão do sistema com tabela temporal com otimização de memória vinculada a uma nova tabela de histórico baseada em disco.

Este exemplo cria uma nova tabela temporal vinculada a uma nova tabela de histórico.

CREATE SCHEMA History;
GO

CREATE TABLE dbo.Department
(
    DepartmentNumber CHAR(10) NOT NULL PRIMARY KEY NONCLUSTERED,
    DepartmentName VARCHAR(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber CHAR(10) NULL,
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH
(
    MEMORY_OPTIMIZED = ON,
    DURABILITY = SCHEMA_AND_DATA,
    SYSTEM_VERSIONING = ON (HISTORY_TABLE = History.DepartmentHistory)
);

Este exemplo cria uma nova tabela temporal vinculada a uma tabela de histórico existente.

-- Existing table
CREATE TABLE Department_History
(
    DepartmentNumber CHAR(10) NOT NULL,
    DepartmentName VARCHAR(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber CHAR(10) NULL,
    ValidFrom DATETIME2 NOT NULL,
    ValidTo DATETIME2 NOT NULL
);

-- Temporal table
CREATE TABLE Department
(
    DepartmentNumber CHAR(10) NOT NULL PRIMARY KEY CLUSTERED,
    DepartmentName VARCHAR(50) NOT NULL,
    ManagerID INT NULL,
    ParentDepartmentNumber CHAR(10) NULL,
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH
(
    SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Department_History, DATA_CONSISTENCY_CHECK = ON)
);

S. Criar uma tabela com colunas criptografadas

O exemplo a seguir cria uma tabela com duas colunas criptografadas. Para obter mais informações, consulte Always Encrypted.

CREATE TABLE Customers (
    CustName NVARCHAR(60)
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = MyCEK,
            ENCRYPTION_TYPE = RANDOMIZED,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ),
    SSN VARCHAR(11) COLLATE Latin1_General_BIN2
        ENCRYPTED WITH (
            COLUMN_ENCRYPTION_KEY = MyCEK,
            ENCRYPTION_TYPE = DETERMINISTIC ,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
        ),
    Age INT NULL
);

T. Criar um índice filtrado embutido

Cria uma tabela com um índice filtrado embutido.

CREATE TABLE t1
(
    c1 INT,
    index IX1 (c1) WHERE c1 > 0
);

U. Criar um índice embutido

O seguinte exemplo mostra como usar NONCLUSTERED embutido em tabelas baseadas em disco:

CREATE TABLE t1
(
    c1 INT,
    INDEX ix_1 NONCLUSTERED (c1)
);

CREATE TABLE t2
(
    c1 INT,
    c2 INT INDEX ix_1 NONCLUSTERED
);

CREATE TABLE t3
(
    c1 INT,
    c2 INT,
    INDEX ix_1 NONCLUSTERED (c1,c2)
);

V. Criar uma tabela temporária com a chave primária composta nomeada de forma anônima

Criar uma tabela com a chave primária composta nomeada de forma anônima. Isso é útil para evitar conflitos de tempo de execução em que duas tabelas temporárias com escopo da sessão, cada uma em uma sessão separada, usam o mesmo nome para uma restrição.

CREATE TABLE #tmp
(
    c1 INT,
    c2 INT,
    PRIMARY KEY CLUSTERED ([c1], [c2])
);
GO

Se você nomear explicitamente a restrição, a segunda sessão gerará um erro, como:

Msg 2714, Level 16, State 5, Line 1
There is already an object named 'PK_#tmp' in the database.
Msg 1750, Level 16, State 1, Line 1
Could not create constraint or index. See previous errors.

O problema é que embora o nome da tabela temporária seja exclusivo, os nomes de restrição não são.

W. Usar tabelas temporárias globais no Banco de Dados SQL do Azure

A sessão A cria uma tabela temporária global ##test no Banco de Dados SQL do Azure testdb1 e adiciona uma linha

CREATE TABLE ##test (
    a INT,
    b INT
);

INSERT INTO ##test
VALUES (1, 1);

-- Obtain object ID for temp table ##test
SELECT OBJECT_ID('tempdb.dbo.##test') AS 'Object ID';

Veja a seguir o conjunto de resultados.

1253579504

Obter o nome da tabela temporária global para uma ID de objeto especificada 1253579504 em tempdb (2)

SELECT name FROM tempdb.sys.objects WHERE object_id = 1253579504;

Veja a seguir o conjunto de resultados.

##test

A Sessão B conecta-se ao Banco de Dados SQL do Azure testdb1 e pode acessar a tabela ##test criado pela sessão A

SELECT * FROM ##test;

Veja a seguir o conjunto de resultados.

1, 1

A Sessão C conecta-se a outro banco de dados no Banco de Dados SQL do Azure testdb2 e deseja acessar ##test criado em testdb1. Esta seleção falha devido ao escopo do banco de dados para as tabelas temporárias globais

SELECT * FROM ##test

Que gera o seguinte erro:

Msg 208, Level 16, State 0, Line 1
Invalid object name '##test'

Processando um objeto do sistema no Banco de Dados SQL do Azure tempdb do banco de dados testdb1 do usuário atual

SELECT * FROM tempdb.sys.objects;
SELECT * FROM tempdb.sys.columns;
SELECT * FROM tempdb.sys.database_files;

X. Habilitar a política de retenção de dados em uma tabela

O exemplo a seguir cria uma tabela com a retenção de dados habilitada e um período de retenção igual a uma semana. Este exemplo só se aplica ao SQL do Azure no Edge.

CREATE TABLE [dbo].[data_retention_table]
(
  [dbdatetime2] datetime2(7),
  [product_code] int,
  [value] char(10)
)
WITH (DATA_DELETION = ON ( FILTER_COLUMN = [dbdatetime2], RETENTION_PERIOD = 1 WEEKS ))

Y. Criando uma tabela do razão atualizável

O exemplo a seguir cria uma tabela do razão atualizável que não é uma tabela temporal com uma tabela de histórico anônima (o sistema gera o nome da tabela de histórico) e o nome da exibição do razão gerada. Como os nomes das colunas necessárias geradas sempre e as colunas adicionais na exibição do razão não são especificados, as colunas recebem os nomes padrão.

CREATE SCHEMA [HR];
GO
CREATE TABLE [HR].[Employees]
(
    EmployeeID INT NOT NULL,
    Salary Money NOT NULL
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);
GO

O exemplo a seguir cria uma tabela temporal e uma tabela do razão atualizável, com uma tabela de histórico anônima (com um nome gerado pelo sistema), o nome de exibição do razão gerado, os nomes padrão das colunas geradas sempre e as colunas adicionais de exibição do razão.

CREATE SCHEMA [HR];
GO
CREATE TABLE [HR].[Employees]
(
    EmployeeID INT NOT NULL PRIMARY KEY,
    Salary Money NOT NULL,
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);
GO

O exemplo a seguir cria uma tabela que é, ao mesmo tempo, uma tabela temporal e uma tabela do razão atualizável com a tabela de histórico nomeada explicitamente, o nome especificado pelo usuário da exibição do razão e os nomes especificados pelo usuário de colunas geradas sempre e colunas adicionais na exibição do razão.

CREATE SCHEMA [HR];
GO
CREATE TABLE [HR].[Employees]
(
    EmployeeID INT NOT NULL PRIMARY KEY,
    Salary Money NOT NULL,
    StartTransactionId BIGINT GENERATED ALWAYS AS TRANSACTION_ID START HIDDEN NOT NULL,
    EndTransactionId BIGINT GENERATED ALWAYS AS TRANSACTION_ID END HIDDEN NULL,
    StartSequenceNumber BIGINT GENERATED ALWAYS AS SEQUENCE_NUMBER START HIDDEN NOT NULL,
    EndSequenceNumber BIGINT GENERATED ALWAYS AS SEQUENCE_NUMBER END HIDDEN NULL,
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
    ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (
    SYSTEM_VERSIONING = ON (HISTORY_TABLE = [HR].[EmployeesHistory]),
    LEDGER = ON (
        LEDGER_VIEW = [HR].[EmployeesLedger] (
            TRANSACTION_ID_COLUMN_NAME = TransactionId,
            SEQUENCE_NUMBER_COLUMN_NAME = SequenceNumber,
            OPERATION_TYPE_COLUMN_NAME = OperationId,
            OPERATION_TYPE_DESC_COLUMN_NAME = OperationTypeDescription
        )
    )
);
GO

O exemplo a seguir cria uma tabela do razão somente de acréscimo com os nomes gerados da exibição do razão e as colunas na exibição do razão.

CREATE SCHEMA [AccessControl];
GO
CREATE TABLE [AccessControl].[KeyCardEvents]
(
    EmployeeID INT NOT NULL,
    AccessOperationDescription NVARCHAR (MAX) NOT NULL,
    [Timestamp] Datetime2 NOT NULL,
    StartTransactionId BIGINT GENERATED ALWAYS AS TRANSACTION_ID START HIDDEN NOT NULL,
    StartSequenceNumber BIGINT GENERATED ALWAYS AS SEQUENCE_NUMBER START HIDDEN NOT NULL
)
WITH (
    LEDGER = ON (
        LEDGER_VIEW = [AccessControl].[KeyCardEventsLedger] (
            TRANSACTION_ID_COLUMN_NAME = TransactionId,
            SEQUENCE_NUMBER_COLUMN_NAME = SequenceNumber,
            OPERATION_TYPE_COLUMN_NAME = OperationId,
            OPERATION_TYPE_DESC_COLUMN_NAME = OperationTypeDescription
        ),
        APPEND_ONLY = ON
    )
);
GO

O exemplo a seguir cria um banco de dados do razão no Banco de Dados SQL do Azure e uma tabela do razão atualizável usando as configurações padrão. A criação de uma tabela do razão atualizável em um banco de dados do razão não requer o uso de WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);.

CREATE DATABASE MyLedgerDB ( EDITION = 'GeneralPurpose' ) WITH LEDGER = ON;
GO

CREATE SCHEMA [HR];
GO

CREATE TABLE [HR].[Employees]
(
    EmployeeID INT NOT NULL,
    Salary Money NOT NULL
)
GO

Partilhar via

CREATE TABLE (Transact-SQL)

Opções de sintaxe

Sintaxe comum

Sintaxe completa

Sintaxe para tabelas com otimização de memória

Argumentos

database_name

schema_name

table_name

AS FileTable

column_name como computed_column_expression

PERSISTED

ON { partition_scheme | filegroup | "default" }

TEXTIMAGE_ON { filegroup | "default" }

FILESTREAM_ON { partition_scheme_name | filegroup | "default" }

[ type_schema_name. ] type_name

CONTENT

DOCUMENT

xml_schema_collection

DEFAULT

IDENTITY

NOT FOR REPLICATION

GENERATED ALWAYS AS { ROW | TRANSACTION_ID | SEQUENCE_NUMBER } { START | END } [ HIDDEN ] [ NOT NULL ]

INDEX index_name [ CLUSTERED | NONCLUSTERED ] ( column_name [ ASC | DESC ] [ ,... n ] )

INDEX index_name CLUSTERED COLUMNSTORE

INDEX index_name [ NONCLUSTERED ] COLUMNSTORE ( column_name [ ,... n ] )

ON partition_scheme_name ( column_name )

ON filegroup_name

ON "padrão"

[ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

ROWGUIDCOL

ENCRYPTED WITH

SPARSE

MASKED WITH ( FUNCTION = 'mask_function' )

FILESTREAM

COLLATE collation_name

CONSTRAINT

column_set_name XML COLUMN_SET FOR ALL_SPARSE_COLUMNS

PERIOD FOR SYSTEM_TIME ( system_start_time_column_name , system_end_time_column_name )

COMPRESSION_DELAY

<table_option> ::=

DATA_COMPRESSION

XML_COMPRESSION

ON PARTITIONS ( { <partition_number_expression> | [ ,... n ] )

<index_option> ::=

PAD_INDEX = { ON | OFF }

FILLFACTOR = fillfactor

IGNORE_DUP_KEY = { ON | OFF }

STATISTICS_NORECOMPUTE = { ON | OFF }

ALLOW_ROW_LOCKS = { ON | OFF }

ALLOW_PAGE_LOCKS = { ON | OFF }

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }

FILETABLE_DIRECTORY = directory_name

FILETABLE_COLLATE_FILENAME = { collation_name | database_default }

FILETABLE_PRIMARY_KEY_CONSTRAINT_NAME = nome_da_restrição

FILETABLE_STREAMID_UNIQUE_CONSTRAINT_NAME = nome_da_restrição

FILETABLE_FULLPATH_UNIQUE_CONSTRAINT_NAME = nome_da_restrição

SYSTEM_VERSIONING = ON [ ( HISTORY_TABLE = schema_name.history_table_name [ , DATA_CONSISTENCY_CHECK = { ON | OFF } ] ) ]

REMOTE_DATA_ARCHIVE = { ON [ ( table_stretch_options [ ,... n ] ) ] | OFF ( MIGRATION_STATE = PAUSED ) }

[ FILTER_PREDICATE = { NULL | predicate } ]

MIGRATION_STATE = { OUTBOUND | INBOUND | PAUSED }

[ DATA_DELETION = ON { ( FILTER_COLUMN = column_name, RETENTION_PERIOD = { INFINITE | number { DAY | DAYS | WEEK | WEEKS | MONTH | MONTHS | YEAR | YEARS } ) } ]

MEMORY_OPTIMIZED

DURABILITY

BUCKET_COUNT

INDEX

LEDGER = ON ( <ledger_option> [ ,... n ] ) | OFF

<ledger_option> ::=

[ LEDGER_VIEW = schema_name.ledger_view_name [ ( <ledger_view_option> [ ,... n ] ) ]

[ APPEND_ONLY = ON | OFF ]

<ledger_view_option> ::=

[ TRANSACTION_ID_COLUMN_NAME = transaction_id_column_name ]

[ SEQUENCE_NUMBER_COLUMN_NAME = sequence_number_column_name ]

[ OPERATION_TYPE_COLUMN_NAME = operation_type_id column_name ]

[ OPERATION_TYPE_DESC_COLUMN_NAME = operation_type_desc_column_name ]

Comentários

Tabelas temporárias

Tabelas temporárias globais no escopo do banco de dados (Banco de Dados SQL do Azure)

Solução de problemas de tabelas temporárias globais para o Banco de Dados SQL do Azure