¿Pones tus índices en control de fuente?

¿Y cómo los mantiene sincronizados entre entornos de testing y producción?

Cuando se trata de índices en tablas de bases de datos, mi filosofía es que son una parte integral de escribir cualquier código que consulte la database. No puede introducir nuevas consultas o cambiar una consulta sin analizar el impacto en los índices.

Así que hago mi mejor esfuerzo para mantener mis índices sincronizados entre todos mis entornos, pero para ser honesto, no me está yendo muy bien para automatizar esto. Es una especie de process manual fortuito.

Revisé periódicamente las statistics de índice y eliminé índices innecesarios. Normalmente hago esto creando un script de eliminación que luego copio a los otros entornos.

Pero aquí y allá los índices se crean y eliminan fuera del process normal y es realmente difícil ver dónde están las diferencias.

He encontrado una cosa que realmente ayuda es ir con nombres de índices numéricos simples, como

idx_t_01 idx_t_02 

donde t es una abreviatura abreviada de una tabla. Encuentro imposible el mantenimiento de índices cuando trato de ser inteligente con todas las columnas involucradas, como,

 idx_c1_c2_c5_c9_c3_c11_5 

Es muy difícil diferenciar índices como ese.

¿Alguien tiene una forma realmente buena de integrar el mantenimiento del índice en el control de la fuente y el ciclo de vida del desarrollo?

Los índices forman parte del esquema de la database y, por lo tanto, deben controlarse por fuente junto con todo lo demás. Nadie debería crear índices de producción sin pasar por el process normal de control de calidad y lanzamiento, en particular las testings de performance.

Ha habido muchos otros subprocesss en el control de versiones de esquema.

El esquema completo para su database debe estar en control de fuente justo al lado de su código. Cuando digo "esquema completo" me refiero a definiciones de tabla, consultas, procedimientos almacenados, índices, todo el lote.

Al realizar una installation nueva, lo hace: – revise la versión X del producto. – desde el directory "database" de su process de pago, ejecute las secuencias de commands de la database para crear su database. – usa la base de código de tu pago para interactuar con la database.

Cuando está desarrollando, cada desarrollador debe trabajar en contra de su propia instancia de database privada. Cuando realizan cambios de esquema, comtestingn un nuevo set de files de definición de esquema que funcionan en comparación con su base de código revisada.

Con este enfoque, nunca tendrá problemas de synchronization de bases de datos de bases de datos.

Sí, cualquier cambio en DML o DDL tiene una secuencia de commands y se registra en el control de fuente, principalmente a través de migraciones de loggings activos en los Rails. Odio continuamente tocar la bocina de los Rails, pero en muchos años de build sistemas basados ​​en DB, encuentro que la ruta de migration es mucho mejor que cualquier sistema de fabricación propia que haya utilizado o construido.

Sin embargo, nombro todos mis índices (no dejes que el DBMS proponga el nombre loco que elija). No los prefija , es una tontería (porque tiene metadatos de tipo en sysobjects, o en cualquier db que tenga), pero sí incluyo el nombre y las columnas de la tabla, por ejemplo, tablename_col1_col2.

De esta manera, si estoy navegando por sysobjects puedo ver fácilmente los índices de una tabla en particular (también es una fuerza de hábito, en realidad con algunos dBMS que utilicé, los nombres de los índices eran únicos en toda la database, así que la única manera para asegurarse de que es usar nombres únicos).

Creo que hay dos problemas aquí: la convención de nomenclatura de índice y la adición de cambios en la database a su control de fuente / ciclo de vida. Voy a abordar el último problema.

He sido progtwigdor de Java durante mucho time, pero recientemente me presentaron un sistema que usa Ruby on Rails para acceder a la database de parte del sistema. Una cosa que me gusta de RoR es la noción de "migraciones". Básicamente, tiene un directory lleno de files que se parecen a 001_add_foo_table.rb, 002_add_bar_table.rb, 003_add_blah_column_to_foo.rb, etc. Estos files de código fuente de Ruby extienden una class principal, anulando los methods llamados "arriba" y "abajo". El método "arriba" contiene el set de cambios de la database que deben realizarse para llevar la versión anterior del esquema de la database a la versión actual. Del mismo modo, el método "abajo" revierte el cambio a la versión anterior. Cuando desee establecer el esquema para una versión específica, los scripts de migration de Rails verifican la database para ver cuál es la versión actual, luego encuentra los files .rb que lo llevan desde arriba (o hacia abajo) a la revisión deseada.

Para hacer esto como parte de su process de desarrollo, puede verificar esto en el control de la fuente y sazonar a gusto.

No hay nada específico o especial acerca de Rails aquí, solo que es la primera vez que veo esta técnica ampliamente utilizada. También puede usar pares de files SQL DDL, como 001_UP_add_foo_table.sql y 001_DOWN_remove_foo_table.sql. El rest es una pequeña cuestión de scripting shell, un ejercicio dejado al lector.

Siempre controlo fuente SQL (DDL, DML, etc.). Su código como cualquier otro. Es una buena práctica

No estoy seguro de que los índices sean los mismos en diferentes entornos, ya que tienen diferentes tamaños de datos. A less que sus entornos de testing y producción tengan los mismos datos exactos, los índices serían diferentes.

En cuanto a si pertenecen al control de la fuente, no estoy realmente seguro.

No pongo mis índices en control de fuente, sino el script de creación de los índices. 😉

Index-naming:

  • IX_CUSTOMER_NAME para el campo "nombre" en la tabla "cliente"
  • PK_CUSTOMER_ID para la key principal,
  • UI_CENTOMER_GUID, para el campo GUID del cliente que es único (por lo tanto, el índice único de "UI").

En mi proyecto actual, tengo dos cosas en el control de fuente: un volcado completo de una database vacía (usando pg_dump -c para que tenga todos los ddl para crear tablas e índices) y una secuencia de commands que determina qué versión de la database tiene. y aplica alteraciones / gotas / agregaciones para llevarlo a la versión actual. El primero se ejecuta cuando estamos instalando en un sitio nuevo, y también cuando QA está comenzando una nueva ronda de testings, y el último se ejecuta en cada actualización. Cuando realiza cambios en la database, debe actualizar ambos files.

Con una aplicación de Grails, los índices se almacenan en el control de código fuente de forma pnetworkingeterminada, ya que está definiendo la definición de índice dentro de un file que representa el object de su dominio. Simplemente ofreciendo la perspectiva de 'Grails' como un FYI.