我们是否将索引置于源代码管理中?
以及如何使它们在测试和生产环境之间保持同步?
当谈到数据库表上的索引时,我的理念是它们是编写任何查询数据库代码的组成部分。如果不分析对索引的影响,就不能引入新查询或者更改查询。
因此,我会尽我所能在所有环境之间保持索引同步,但是老实说,我在自动执行此操作方面做得不好。这是一种偶然的手动过程。
我定期查看索引统计信息并删除不必要的索引。我通常通过创建一个删除脚本来执行此操作,然后将其复制回其他环境。
但是在正常过程之外,这里和那里的索引都是被创建和删除的,要查看差异在哪里真的很困难。
我发现真正有用的一件事是使用简单的数字索引名称,例如
idx_t_01 idx_t_02
其中t是表的缩写。当我尝试使所有涉及的列变得聪明时,我发现无法进行索引维护,例如,
idx_c1_c2_c5_c9_c3_c11_5
很难区分这样的索引。
是否有人真的有很好的方法将索引维护集成到源代码控制和开发生命周期中?
解决方案
是的,所有DML或者DDL更改都已编写脚本并签入到源代码管理中,主要是通过在rails中进行activerecord迁移。我讨厌不断抱怨,但是在构建基于DB的系统的许多年中,我发现迁移路径比我使用或者构建的任何本地系统都要好得多。
但是,我确实为所有索引命名(不要让DBMS拿出任何疯狂的名字)。不要给它们加上前缀,这很愚蠢(因为我们在sysobjects或者我们拥有的任何数据库中都有类型元数据),但是我确实包含了表名和列,例如tablename_col1_col2.
这样,如果我正在浏览sysobjects,就可以轻松查看特定表的索引(这也是一种习惯,这在我过去使用的某些dBMS上很常见,索引名称在整个数据库中是唯一的,所以唯一的方法以确保使用唯一名称)。
索引是数据库模式的一部分,因此应该与其他所有内容一起进行源代码控制。在没有经过正常的质量检查和发布过程尤其是性能测试的情况下,任何人都不应四处创建生产索引。
模式版本控制还有许多其他线程。
我没有将索引放在源代码管理中,而是在索引的创建脚本中。 ;-)
索引命名:
- IX_CUSTOMER_NAME用于表"客户"中的字段"名称"
- 主键PK_CUSTOMER_ID,
- UI_CUSTOMER_GUID,用于客户的GUID字段,该字段是唯一的(因此为" UI"-唯一索引)。
数据库的完整架构应在代码旁边的源代码控制中。当我说"完整模式"时,我的意思是表定义,查询,存储过程,索引等等。
全新安装时,我们可以执行以下操作:
签出产品的X版本。
从结帐的"数据库"目录中,运行数据库脚本来创建数据库。
使用结帐中的代码库与数据库进行交互。
在进行开发时,每个开发人员都应针对自己的私有数据库实例进行工作。当他们进行模式更改时,他们签入一组新的模式定义文件,这些文件针对其修订后的代码库而工作。
使用这种方法,我们永远不会遇到代码库与数据库同步的问题。
我总是使用源代码控制SQL(DDL,DML等)。它的代码与其他任何代码一样。它的好习惯。
我不确定索引在不同环境中是否应该相同,因为它们具有不同的数据大小。除非测试和生产环境具有相同的确切数据,否则索引将不同。
至于它们是否属于源代码控制,还不确定。
我认为这里有两个问题:索引命名约定,以及将数据库更改添加到源代码控制/生命周期中。我将解决后一个问题。
我很久以来一直是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脚本的小问题,这是留给读者的练习。
在我当前的项目中,我在源代码管理中有两件事:空数据库的完整转储(使用pg_dump -c,以便它具有创建表和索引的所有ddl)和一个脚本,该脚本确定我们拥有的数据库版本,以及应用更改/删除/添加以将其升级到当前版本。前者在我们在新站点上安装时运行,并且在QA开始新一轮测试时运行,而后者在每次升级时运行。更改数据库时,需要更新这两个文件。
段落数量不匹配