那么如何让它们在测试和生产环境之间保持同步？
当谈到数据库表的索引时,我的理念是它们是编写查询数据库的任何代码的不可或缺的一部分.如果不分析对索引的影响,则无法引入新查询或更改查询.
因此,我尽力使我的索引在我的所有环境之间保持同步,但说实话,我在自动化方面做得并不好.这是一种随意的手动过程.
我定期检查索引统计信息并删除不必要的索引.我通常通过创建一个删除脚本来执行此操作,然后将其复制回其他环境.
但是这里和那里的索引在正常过程之外被创建和删除,并且很难看出差异在哪里.
我发现一件真正有用的事情就是使用简单的数字索引名称,比如
idx_t_01 idx_t_02
其中t是表的简短缩写.当我试图让所有相关的列变得聪明时,我发现索引维护是不可能的,例如,
idx_c1_c2_c5_c9_c3_c11_5
区分这样的索引太难了.
有没有人有一个非常好的方法将索引维护集成到源代码控制和开发生命周期？
索引是数据库模式的一部分,因此应该与其他所有内容一起进行源代码控制.在没有通过正常的质量保证和发布流程(特别是性能测试)的情况下,没有人应该在生产中创建索引.
模式版本控制上有许多其他线程.
数据库的完整模式应位于代码旁边的源代码管理中.当我说"完整模式"时,我指的是表定义,查询,存储过程,索引,整个批次.
在进行全新安装时,您可以: - 查看产品的X版本. - 从结帐的"数据库"目录中,运行数据库脚本以创建数据库. - 使用结账时的代码库与数据库进行交互.
在开发时,每个开发人员都应该针对自己的私有数据库实例.当他们进行架构更改时,他们会检查一组新的架构定义文件,这些文件对其修订的代码库起作用.
使用这种方法,您永远不会遇到代码库 - 数据库同步问题.
是的,任何 DML或DDL更改都是编写脚本并签入源代码控制的,主要是通过rails中的activerecord迁移.我讨厌不断嘟嘟Rails的号角,但在很多年的时间打造基于数据库的系统,我发现迁徙路线比任何本土的系统我用或内置好多了.
但是,我确实命名了所有索引(不要让DBMS提出它选择的任何疯狂的名字).不要前缀他们,那是愚蠢的(因为你必须在sysobjects类型的元数据,或者你有什么分贝),但我不包括表名和列,如tablename_col1_col2.
这样,如果我正在浏览sysobjects,我可以很容易地看到特定表的索引(这也是一种习惯的力量,在我使用的某些dBMS上当天回归,索引名称在整个数据库中是唯一的,所以唯一的方法确保使用唯一的名称).
京公网安备 11010802040832号 | 京ICP备19059560号-6 