【问题标题】:Do you put your indexes in source control?您是否将索引放在源代码管理中?
【发布时间】:2010-09-14 06:10:31
【问题描述】:

您如何使它们在测试和生产环境之间保持同步?

当谈到数据库表的索引时,我的理念是它们是编写任何查询数据库的代码的一个组成部分。如果不分析对索引的影响,就不能引入新查询或更改查询。

所以我尽我所能保持我所有环境之间的索引同步,但老实说,我在自动化这方面做得不是很好。这是一种随意的手动过程。

我会定期查看索引统计信息并删除不必要的索引。为此,我通常会创建一个删除脚本,然后将其复制回其他环境。

但有时索引会在正常流程之外创建和删除,很难看出差异在哪里。

我发现真正有用的一件事是使用简单的数字索引名称,例如

idx_t_01
idx_t_02

其中 t 是表格的缩写。当我试图巧妙处理所有涉及的列时,我发现索引维护是不可能的,比如,

idx_c1_c2_c5_c9_c3_c11_5

这样区分索引太难了。

有没有人将索引维护集成到源代码控制和开发生命周期中的真正好方法?

【问题讨论】:

    标签: sql database version-control indexing sdlc


    【解决方案1】:

    是的,任何 DML 或 DDL 更改都会编写脚本并签入源代码控制,主要是通过 rails 中的 activerecord 迁移。我讨厌不断地吹牛,但在多年构建基于 DB 的系统的过程中,我发现迁移路线比我使用或构建的任何本土系统都要好得多。

    但是,我确实为我的所有索引命名(不要让 DBMS 想出它选择的任何疯狂的名称)。 不要给它们添加前缀,这很愚蠢(因为您在 sysobjects 或您拥有的任何数据库中都有类型元数据),但我确实包含了表名和列,例如表名_col1_col2。

    这样,如果我正在浏览 sysobjects,我可以很容易地看到特定表的索引(这也是一种习惯的力量,在我使用的一些 dBMS 上,索引名称在整个数据库中都是唯一的,所以确保这一点的唯一方法是使用唯一的名称)。

    【讨论】:

      【解决方案2】:

      索引是数据库架构的一部分,因此应该与其他所有内容一起进行源代码控制。没有经过正常的 QA 和发布流程(尤其是性能测试),任何人都不应该在生产环境中创建索引。

      还有许多其他关于模式版本控制的线程。

      【讨论】:

        【解决方案3】:

        我没有将我的索引放在源代码管理中,而是将索引的创建脚本。 ;-)

        索引命名:

        • “客户”表中“名称”字段的 IX_CUSTOMER_NAME
        • PK_CUSTOMER_ID 为主键,
        • UI_CUSTOMER_GUID,用于唯一的客户 GUID 字段(因此是“UI” - 唯一索引)。

        【讨论】:

          【解决方案4】:

          数据库的完整架构应该在代码旁边的源代码控制中。当我说“完整架构”时,我指的是表定义、查询、存储过程、索引等等。

          进行全新安装时,您可以: - 查看产品的 X 版本。 - 从结帐的“数据库”目录中,运行数据库脚本来创建数据库。 - 使用结帐中的代码库与数据库交互。

          当您进行开发时,每个开发人员都应该使用自己的私有数据库实例。当他们进行架构更改时,他们会检查一组新的架构定义文件,这些文件适用于他们修改后的代码库。

          使用这种方法,您永远不会遇到代码库-数据库同步问题。

          【讨论】:

            【解决方案5】:

            我总是对 SQL 进行源代码控制(DDL、DML 等)。它的代码和其他代码一样。这是一个很好的做法。

            【讨论】:

              【解决方案6】:

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

              至于它们是否属于源代码管理,我不确定。

              【讨论】:

              • 有了一个像样的数据库,这无关紧要,优化器/规划器的工作就是决定它是否要使用索引。您应该在所有环境中都拥有它,否则在生产之前您可能看不到由索引维护引起的性能问题。
              【解决方案7】:

              我认为这里有两个问题:索引命名约定,以及将数据库更改添加到源代码控制/生命周期。我会解决后一个问题。

              我从事 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 脚本的小事,留给读者练习。

              【讨论】:

                【解决方案8】:

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

                【讨论】:

                  【解决方案9】:

                  使用 grails 应用程序,索引默认存储在源代码管理中,因为您在代表域对象的文件中定义索引定义。仅提供“Grails”视角作为仅供参考。

                  【讨论】:

                    猜你喜欢
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 2010-11-25
                    • 2012-08-18
                    • 2017-04-20
                    • 1970-01-01
                    相关资源
                    最近更新 更多