您是否将索引放入源代码控制?

3
如何在测试环境和生产环境之间保持同步?
对于数据库表上的索引,我的理念是它们是查询数据库时编写任何代码的必要部分。您不能引入新的查询或更改查询而不分析索引的影响。
因此,我尽力将我的索引保持在所有环境之间同步,但老实说,我没有很好地自动化这个过程。这是一种有点混乱的手动过程。
我定期审查索引统计信息并删除不必要的索引。我通常通过创建一个删除脚本来完成这个操作,然后将其复制回其他环境。
但是偶尔会在正常流程之外创建和删除索引,很难看到差异在哪里。
我发现简单的数字索引名称非常有帮助,例如
idx_t_01
idx_t_02

t是表的简称。当我试图在所有涉及的列上巧妙处理时,索引维护变得不可能。

idx_c1_c2_c5_c9_c3_c11_5

区分这样的索引太难了。

有没有一种非常好的方法将索引维护集成到源代码控制和开发生命周期中呢?

9个回答

11

索引是数据库架构的一部分,因此应该和其他所有内容一起进行源代码控制。在不经过正常QA和发布流程特别是性能测试的情况下,在生产环境中创建索引是不可取的。

关于架构版本控制已经有很多其他线程讨论过了。


6
你的完整数据库模式应该与代码一起放在源代码控制中。当我说“完整的模式”时,我指的是表定义、查询、存储过程、索引等所有内容。
在进行新安装时,你需要: - 检查产品版本X。 - 从你的检出目录中的“数据库”目录运行数据库脚本以创建你的数据库。 - 使用检出的代码库与数据库交互。
在开发时,每个开发人员都应该使用自己的私有数据库实例。当他们进行模式更改时,他们会提交一个新的模式定义文件集,这些文件集适用于他们修改后的代码库。
采用这种方法,你就不必担心代码库和数据库同步问题。

5

是的,任何DML或DDL更改都会被编写成脚本并检入源代码控制系统,主要通过rails中的activerecord迁移。我不想一直吹嘘rails的优点,但在多年构建基于数据库的系统的经验中,我发现迁移路线比我使用或构建的任何自定义系统都要好得多。

然而,我确实为所有索引命名(不要让DBMS选择任意名称)。不要加前缀,这很愚蠢(因为你在sysobjects中有类型元数据,或者在你有的任何数据库中),但我包括表名和列名,例如tablename_col1_col2。

这样,如果我浏览sysobjects,我可以轻松地查看特定表的索引(也是一种习惯,很早以前在某些dBMS上,索引名称在整个DB中是唯一的,所以确保使用唯一名称的唯一方法就是使用唯一名称)。


1

我认为这里有两个问题:索引命名约定和将数据库更改添加到您的源代码控制/生命周期中。 我将解决后者的问题。

我一直是一名Java程序员,但最近接触到了一个使用Ruby on Rails作为系统部分的数据库访问的系统。RoR的一个优点是“迁移”的概念。基本上,您有一个目录,其中包含类似于001_add_foo_table.rb、002_add_bar_table.rb、003_add_blah_column_to_foo.rb等文件。这些Ruby源文件扩展了一个父类,覆盖了称为“up”和“down”的方法。 “up”方法包含需要进行的数据库更改集,以将数据库模式的上一个版本带到当前版本。同样,“down”方法将更改恢复到先前版本。当您想要设置特定版本的模式时,Rails迁移脚本会检查数据库以查看当前版本,然后找到从那里上升(或下降)到所需修订版的.rb文件。

为了使其成为您开发过程的一部分,您可以将它们检入源代码控制,并适当调整。

这里与Rails无关,只是这是我第一次看到这种技术被广泛使用。您也可以使用SQL DDL文件的成对方式,例如001_UP_add_foo_table.sql和001_DOWN_remove_foo_table.sql。其余部分只是一些小的shell脚本编写问题,留给读者自行练习。


0

我不将我的索引放在源代码控制中,但会将索引的创建脚本放进去。;-)

索引命名:

  • 对于表“customer”中的字段“name”,使用“IX_CUSTOMER_NAME”
  • 对于主键,使用“PK_CUSTOMER_ID”
  • 对于客户唯一标识符GUID字段,使用“UI_CUSTOMER_GUID”,因为它是唯一的(因此采用“UI”-唯一索引)

0
我总是对SQL进行源代码控制(DDL,DML等)。它就像任何其他代码一样。这是良好的编程实践。

0

我不确定在不同的环境中索引是否应该相同,因为它们具有不同的数据大小。除非您的测试和生产环境具有完全相同的数据,否则索引将不同。

至于它们是否属于源代码控制,我不太确定。


有了一个不错的数据库,这就不重要了,优化器/计划器的工作是决定是否使用索引。你应该在所有环境中都使用它,否则你可能直到生产环境才会看到由索引维护引起的性能问题。 - Matthew Watson

0
在我的当前项目中,我有两个东西在源代码控制中 - 一个空数据库的完整转储(使用pg_dump -c,因此它具有创建表和索引的所有ddl),以及一个脚本,确定您拥有哪个版本的数据库,并应用更改/删除/添加以将其升级到当前版本。前者在我们安装新站点时运行,也在QA开始新一轮测试时运行,后者在每次升级时运行。当您进行数据库更改时,必须更新这两个文件。

0

使用Grails应用程序时,默认情况下索引存储在源代码控制中,因为您正在定义表示域对象的文件中的索引定义。这只是提供“Grails”视角作为FYI。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接