SQL 服务器标准版 2014 中的聚集列存储索引？
Clustered Columnstore Index in SQL Server Standard Edition 2014?
我做了一个数据库项目，原本应该部署到 SQL Server Enterprise Edition 2014。
项目中的某些表具有聚簇列存储索引。
据我所知，SQL Server Standard Edition 2014 不支持聚集列存储索引。
我的问题是：如果有人试图将这个带有 CCI 的数据库项目部署到标准版，会发生什么情况？
是否仍会创建表，但没有索引，或者整个项目部署会失败吗？
不幸的是，我无法自行测试，因为我只有 SQL 服务器的开发人员版本，其中包括所有企业功能。
正如 Gordon 在上面所建议的那样，这一切都取决于部署机制，但它很有可能会失败（IMO 应该如此）。此外，如果部署是在发生故障时回滚的事务中处理的。
很少有部署系统会付出额外的努力来确定目标 RDBMS 支持哪些功能，并且大多数应该遵循 'This is in my code repository, deploy it' 的规则。允许它做其他事情可能会引入重大变化。
TBH 最好的办法是在源存储库中保留代码集的两个分支 - 一个带有 xVelocity 索引，一个没有。或者先部署到 Developer 实例，然后 运行 一个脚本来剥离您知道的企业功能，然后编写这些更改以部署到下游 SKU。
是的，这需要更多工作，需要定期将代码与更改合并，或者创建下游代码。但它至少可以让您从定义良好的代码集进行部署。
如果您绝对必须从企业派生脚本进行部署，那么您将考虑滚动您自己的部署脚本。
顺便说一句（并不是说它对 2014 年有帮助），从 Sql Server 2016 SP1 开始，Microsoft 改变了竞争环境并允许 99% 的企业功能所有 SKU - 这包括 CCI 的
我做了一个数据库项目，原本应该部署到 SQL Server Enterprise Edition 2014。 项目中的某些表具有聚簇列存储索引。 据我所知，SQL Server Standard Edition 2014 不支持聚集列存储索引。
我的问题是：如果有人试图将这个带有 CCI 的数据库项目部署到标准版，会发生什么情况？ 是否仍会创建表，但没有索引，或者整个项目部署会失败吗？
不幸的是，我无法自行测试，因为我只有 SQL 服务器的开发人员版本，其中包括所有企业功能。
正如 Gordon 在上面所建议的那样，这一切都取决于部署机制，但它很有可能会失败（IMO 应该如此）。此外，如果部署是在发生故障时回滚的事务中处理的。
很少有部署系统会付出额外的努力来确定目标 RDBMS 支持哪些功能，并且大多数应该遵循 'This is in my code repository, deploy it' 的规则。允许它做其他事情可能会引入重大变化。
TBH 最好的办法是在源存储库中保留代码集的两个分支 - 一个带有 xVelocity 索引，一个没有。或者先部署到 Developer 实例，然后 运行 一个脚本来剥离您知道的企业功能，然后编写这些更改以部署到下游 SKU。
是的，这需要更多工作，需要定期将代码与更改合并，或者创建下游代码。但它至少可以让您从定义良好的代码集进行部署。
如果您绝对必须从企业派生脚本进行部署，那么您将考虑滚动您自己的部署脚本。
顺便说一句（并不是说它对 2014 年有帮助），从 Sql Server 2016 SP1 开始，Microsoft 改变了竞争环境并允许 99% 的企业功能所有 SKU - 这包括 CCI 的