Non nobis Domine...
Isaac Ruiz Guerra's Weblog
- Todo
- Internet
- Politica
- frases
- ruby
- ESB
- Libros
- Oracle
- SOA
- Haskell
- Urbi
- 97things
- Humor
- General
- Justicia Social
- Cine
- Java
- TecNo
[3 de 97]. Controla los datos, no sólo el código.
El axioma de hoy dice:
Control de data, no just de code.
Chad LaVigne
Chad LaVigne,
es un arquitecto que trabaja en TEKSystems, Inc, participa
activamente en la comunidad openSource y dirige un JUG en las oficinas
de su compañía.
Aquí las partes que considero mas relevantes del axioma (tomado del libro 97
things Every Software Architech Should Know ):
Control de data, no just de code.
Source code control and continuous integration are excellent tools for managing the application build and deployment process. Along with source code, schema and data changes are often a significant part of this process and thus warrant similar controls. If your build and deployment process includes a list of elaborate steps required for data updates, beware.
....
Database changes shouldn’t create a ripple in your build’s time-space continuum. You need to be able to build the entire application, including the database, as one unit. Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends. At best it will save hours of painful, high-stress problem solving after a late night blunder. At worst it will give your team the ability to confidently charge forward with refactoring of the data access layer.
Creo que la culpa de que antaño no le dábamos tanta importancia a todo lo que tiene que ver con scripts de base de datos es que, era una tarea, en el mejor de los casos tediosa, y en el peor algo muy complejo de explicar a los clientes
Pero conforme vamos participando en proyectos nos vamos dando cuenta que, buena parte del éxito de nuestra aplicación esta en función de qué tan bien este diseñada y mantenida por los DBA's.
Y conforme han evolucionado las metodologías y técnicas para el desarrollo e integración de aplicaciones y con el advenimiento de los métodos ágiles, creo que ha llegado la hora de incluir a las bases de datos su merecido lugar en la foto.
Una de mis peores pesadillas siempre ha sido realizar un update a una tabla de configuración para alterar un registro y cuando hago el commit me doy cuenta que he pasado por alto la sentencia WHERE..... ¡¡¡ Una catástrofe!!!; Afortunadamente el tener scripts de poblado inicial (¿es correcto llamarlo así?) de dichas tablas siempre te da la tranquilidad de saber que puedes regresar a un "estado correcto" {ocupando un poco terminología de greeneyed-ista ;)}
Y no sólo se requieren scripts de poblado inicial, por supuesto requerimos los de:
- Creación/Eliminación de tablas
- Creación/Eliminación de procedimientos almacenados (Stores procedures).
- Creación/Eliminación de disparadores(triggers).
- Creación/Eliminación de secuencias
- etc,etc
Si aun no te ha tocado estar en un conferencia telefónica en donde todo el mundo esta al borde de la histeria pues no saben que es lo que ha faltado(y hace inoperable el ambiente) de migrar en la nueva y reluciente base de datos recién adquirida (por muchos miles de $), entonces, ten a la mano la siguiente pregunta, toma aire y con humilde autoridad dí:
Hombre ¿No será que se les ha pasado migrar los stores y los triggers?Si la estadística no falla, toda la línea de mando del DBA guardará silencio y el gerente en turno dirá:
Bueno, revisaremos eso y luego te llamamos.
Esa llamada nunca llega ;)
Pero bueno, regresando al punto inicial, en estos tiempo en que
requerimos ser más que ágiles, es buena idea considerar
agregar este tipo de estrategias para tener un poco más de
control sobre nuestros desarrollos y permitir, por fin, crear un
ambiente de desarrollo más sano y menos estresante.
A todo esto, sólo me queda preguntar:
¿Has tomado en cuenta los scripts de datos para ofrecer una
solución integral en
tus aplicaciones?
Saludos!!
---
RuGI
Isaac Ruiz Guerra.
Posted at 09:26PM may 31, 2009 by Isaac Ruiz Guerra in 97things | Comentarios[6]
Me ha pasado alguna vez de enviar el nuevo war y que se me olvidará enviarle los nuevos procedimientos almacenados. :-(
Así que intento evitar en la medida de lo posible usar triggers o procedimientos almacenados. Luego nadie se acuerda de ellos pasado un tiempo.Y más aún si hay pocos y casi nunca se cambian.
Enviado por logongas en junio 01, 2009 a las 03:06 AM CDT #
Que hay Rugi!
Hoy he conseguido sacar algo de tiempo para felicitarte por esta serie de posts que has comenzado y para animarte a que continúes con ellos (se en carnes propias lo difícil que es mantener un buen ratio de posts en un blog). Me parece que das en el clavo con las explicaciones de los axiomas (y que buenas las tiras ;-))
Por completar, no estaría mal un pequeño addendum sobre cómo llevar a la práctica la recomendación: una especie de "Implementation details" ;-). Y para no ser el típico gorrón completo un poco ;-):
En el proyecto en el que estamos utilizamos como motor de persistencia hibernate, y en la fase en la que estamos, aún no hemos necesitado almacenar scripts de generación del schema. Así que con guardar las versiones de nuestras entidades, podemos generar fácilmente la BD para cualquier revisión.
[Continúo en otro comentario... comment.lenght > 1000 => spam: ¿WTF?]
Enviado por Ibon Urrutia en junio 01, 2009 a las 05:44 AM CDT #
[... viene de arriba]
Tenemos una pequeña importación de datos, pero en hibernate basta con tener en el classpath de la aplicación un fichero "import.sql" para que lo ejecute al inicio.
Por ahora nos basta con esto, pero en paralelo deberemos crear scripts de importación de bases de datos heredadas (con millones de registros). Como aún no nos hemos puesto manos a la obra no sé lo que implicará a corto o medio plazo (si bastará con scripts de importación o deberemos cambiar el schema diseñado con hibernate), pero hace un tiempo le eché un ojo a un proyecto open source que ayudaba a generar deltas de db (he perdido el enlace y su nombre :-().
Un buen post sobre el tema (más que nada porque reúne en forma de índice otros posts interesantes sobre el tema) es: http://www.codinghorror.com/blog/archives/001050.html
Salu2!
Enviado por Ibon Urrutia en junio 01, 2009 a las 05:44 AM CDT #
Hola Rugi, saludos desde Chile. He estado escuchando los podcast de JavaHispano y por ahí conocí a la comunidad.
Bueno, solamente quería comentarte que Martin Fowler también hace un comentario acerca del "versionamiento de la BD" en su artículo "Evolutionary Database Desgin" http://martinfowler.com/articles/evodb.html
Claro que en ese artículo no explica cómo se implementa lo que él propone.
Saludos!
Germán
Enviado por Germán G. en junio 01, 2009 a las 09:54 PM CDT #
@logongas , pues, de igual manera, si el proyecto lo permite, tambien evito utilizar stores y triggers, pero, hay veces que la misma naturaleza del proyecto o de la empresa te obligan a recurrir a ellos :(
Lo que he hecho en esos casos es crear en la documentación de implantación un apartado que casi titulo: "LEER ANTES DE EJECUTAR" y ahi precisamente indico que deben revisar los triggers :P
@ibon... un verdadero aliciente motivacional que te parezcan interesantes estos post's,
prometo tomar en cuenta lo del addendum, sólo espero hacerlo de la mejor manera.
Gracias por el link!!
Saludos y gracias por visitar el blog :D
--
RuGI
Enviado por RuGI en junio 01, 2009 a las 09:59 PM CDT #
Hola German!
Le daré un vistazo al artículo que mencionas.... si lo escribio Martin F.... algo bueno debe tener. ;)
Saludos desde la capital Azteca!!
---
RuGI
Enviado por RuGI en junio 01, 2009 a las 10:00 PM CDT #