将参数放入 SQL 表创建脚本中的 IDENTITY(1,1) 属性中

发布于 2025-01-11 10:09:23 字数 180 浏览 0 评论 0原文

我想使用参数设置自定义身份。例如:

CREATE TABLE Pets (
    PetId int IDENTITY(@Parameter,1) PRIMARY KEY, 
    PetName varchar(255)
    );

My SQL 解析器不接受这样的语法。

I would like to set custom Identity with parameters. For example:

CREATE TABLE Pets (
    PetId int IDENTITY(@Parameter,1) PRIMARY KEY, 
    PetName varchar(255)
    );

My SQL parser does not accept such syntax.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

落叶缤纷 2025-01-18 10:09:23

您可以使用动态 SQL,但这似乎不对。

DECLARE @Parameter int = 1000;

DECLARE @sql nvarchar(max) = N'CREATE TABLE dbo.Pets 
  (
    PetId int IDENTITY(' 
      + CONVERT(varchar(12), TRY_CONVERT(int,@Parameter)) 
      + ',1) PRIMARY KEY, 
    PetName varchar(255)
  );';

EXEC sys.sp_executesql @sql;

You can use dynamic SQL but this doesn't seem right.

DECLARE @Parameter int = 1000;

DECLARE @sql nvarchar(max) = N'CREATE TABLE dbo.Pets 
  (
    PetId int IDENTITY(' 
      + CONVERT(varchar(12), TRY_CONVERT(int,@Parameter)) 
      + ',1) PRIMARY KEY, 
    PetName varchar(255)
  );';

EXEC sys.sp_executesql @sql;
提赋 2025-01-18 10:09:23

虽然您确实需要在 CREATE TABLE 语句中使用带有 IDENTITY 的文字整数(或根本不需要),但您可以重置 IDENTITY 种子值使用支持参数的DBCC CHECKIDENT 创建表后。

另外:

  • 使用 SQL Server 时,您应该始终使用其父架构完全限定对象名称(默认为 dbo),否则可能会在不同的架构中创建对象,并且在以下情况下将无法解析名称:从其他模式中的对象寻址(它也有助于性能)。
  • 另外,这里还有一些主动提供的数据库设计和数据建模指南:
    • 一般来说,所有列都应为NOT NULL,除非您绝对确定不是这样。
      • 尤其对于文本列:没有什么比处理同时包含 NULL 和空白 '' 值的文本列更烦人的了并且不知道两者之间是否存在任何语义差异。
        • 奖励宾果:如果该列还包含非空但空白字符串。伙计们,这就是 CHECK 约束的用途!
    • 此外,烦人,如果您在 CREATE TABLE 中未指定 NOT NULLNULL列规范,则 SQL Server 默认假设 NULL
  • 名称或任何包含人类可读文本的文本列通常应为 nvarchar 而不是 varchar。
    • 这不适用于其 varchar 类型本身支持 Unicode 的其他 RDBMS。
    • 例外情况是使用 SQL Server 对 UTF-8 的奇怪实现的支持时,但这是另一个讨论的问题了。

无论如何,像这样:

CREATE TABLE dbo.Pets (
    PetId   int           NOT NULL IDENTITY PRIMARY KEY,
    PetName nvarchar(255) NOT NULL
);

GO

DBCC CHECKIDENT ( dbo.Pets, RESEED, @newIdentitySeed );
  • GO 语句是为了 SSMS 的利益;如果您从程序代码中使用此命令,则可能需要将 DBCC CHECKIDENT 命令移动到单独的命令批处理中。

关于权限的重要警告

  • 我假设人们希望运行DBCC CHECKIDENT来重置表的状态,以运行自动集成测试或其他一些他们有的开发/测试场景>sysadmindb_owner 级权限,在这种情况下没有问题。
  • 但是,如果您没有 sysadmin(服务器级)、db_owner(数据库级)或 db_ddladmin(数据库级)权限那么您将无法使用DBCC CHECKIDENT,即使您可以创建表的副本、DROP TABLE原始表并重新创建它作为新的来自文字的 IDENTITY - 这很愚蠢。
    • 在这种情况下,请向您的系统管理员寻求帮助并向他们展示此页面
    • 此外,请参阅 Aaron 在该答案评论中的注释。

While you do need to use a literal integer (or none at all) with IDENTITY in CREATE TABLE statements, you can reset the IDENTITY seed value after you've created the table using DBCC CHECKIDENT which does support parameters.

Also:

  • When working with SQL Server you should always fully-qualify object names with their parent schema (the default is dbo), otherwise objects might be created in a different schema and names won't be resolved when addressed from objects in other schemas (it helps performance too).
  • Also, here's some unsolicted database design and data-modelling pointers:
    • Generally speaking, all columns should be NOT NULL unless you're absolutely certain otherwise.
      • Especially for textual columns: there's nothing quite as annoying as having to deal with a textual column containing both NULL and blank '' values and no clue about if there's any semantic difference between the two.
        • Bonus bingo: if the column also contains non-empty but whitespace strings. This is what CHECK constraints are for, folks!
    • Also, annoyingly, if you don't specify either NOT NULL or NULL in a CREATE TABLE column specification then SQL Server defaults to assuming NULL.
  • Names, or really any textual column containing human-readable text should generally be nvarchar and not varchar.
    • This doesn't apply to other RDBMS where their varchar types natively support Unicode.
    • The exception to this is when using SQL Server's oddly-implemented support for UTF-8, but that's another discussion.

Anyway, like this:

CREATE TABLE dbo.Pets (
    PetId   int           NOT NULL IDENTITY PRIMARY KEY,
    PetName nvarchar(255) NOT NULL
);

GO

DBCC CHECKIDENT ( dbo.Pets, RESEED, @newIdentitySeed );
  • The GO statement is for the benefit of SSMS; if you're using this from program code you might need to move the DBCC CHECKIDENT command to a separate command-batch.

Important caveat about permissions:

  • I assume people would want to run DBCC CHECKIDENT to reset a table's state for running automated integration tests or some other dev/test scenario where they have sysadmin or db_owner-level permissions, in which case there's no problem.
  • But if you don't have sysadmin (Server-level), db_owner (DB-level), or db_ddladmin (DB-level) permissions then you won't be able to use DBCC CHECKIDENT, even though you can create a copy of the table, DROP TABLE the original table and recreate it with as new IDENTITY from a literal - which is just silly.
    • In that case, ping your sysadmin for assistance and show them this page.
    • Also, see the notes from Aaron in the comments for this answer.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文