我正在运行Microsoft SQL Server 15 (2019)的本地实例，并使用Microsoft SQL Server Management Studio v18.9.1 (SSMS)作为客户端来完成创建应用程序所需的表的过程。请注意，我下面的查询的解决方案需要与Microsoft SQL Server 13 (2016)向后兼容。
这一切都是在Windows 10下运行的。
我和一位同事正在致力于实现一个数据库。我正在定义表，编写.sql脚本来创建这些表，并编写.sql脚本来插入示例数据。我的同事将编写代码来解析我们以特殊方式存储在平面文件中的真实数据，并以编程方式将数据插入到我正在开发的数据库中。他将使用我编写的插入示例数据的脚本作为使用 API 的指南，该 API 允许他以编程方式将我们的真实数据插入到我们的数据库中。
在迭代开发过程中，我不断运行脚本来创建表、向其中插入示例数据并进行一些查询。然后，我将通过对脚本进行任何所需的更改、删除所有表，然后重复进行迭代。
我和我的同事显然会互相踩踏。例如，当他尝试以编程方式插入一些数据时，我可能会删除所有表。或者，他可能会在我运行脚本插入示例数据和运行脚本进行一些查询之间以编程方式插入一些数据，从而产生意外的结果。
因此，我使用两种模式。（在这里，我使用我所认为的“模式”一词的“命名空间”含义。）将它们称为dbo（即默认模式）和foo。我将使用foo，我的同事将使用dbo。
在我的.sql脚本中，所有表引用都以“ dbo. ”为前缀。我不想在脚本中对架构进行硬编码，也不必频繁搜索/用“ .foo ”替换“ .dbo ”，反之亦然，我想参数化脚本应使用的架构。