Mostrando entradas con la etiqueta base de datos. Mostrar todas las entradas
Mostrando entradas con la etiqueta base de datos. Mostrar todas las entradas

martes, marzo 06, 2012

Una Dosis de Normalización

Nota: Este artículo fué escrito por el Ing. Alexander Calderon Peraza, docente de la Universidad de El Salvador sede Santa Ana, pueden leer más artículos en http://basesdedatosues.blogspot.com/ y seguirlo en  @calderonperaza.


Desde el punto de vista de los programadores, administradores de bases de datos, y demás afines a la informática, normalización es un paradigma con el cual se busca que una base de datos relacional minimice los problemas de coherencia de datos.

Este articulo busca refrescarnos las primeras formar normales, y abordar el primer paso en lo que muchos consideran formas normales avanzadas, no quiero profundizar en los detalles teóricos, pues esos los encuentran en los miles de libros aburridos de bases de datos que están en la red, en lugar de ello quiero llevarlos por un recorrido practico que nos dirija el día de hoy hasta la Forma Normal de Boyce-Codd.

En primer lugar planteamos un escenario: un modelo entidad relación para registra las visitas que realizan los empleados a distintos inmuebles registrados en la empresa, el empleado visita la vivienda y elabora unas observaciones al respecto, para realizar las visitas al empleado se le proporciona un vehículo para el rápido desplazamiento, la tabla RevisionVivienda almacena la información referida a las revisiones realizadas. Dedique 1 minuto para observar la figura y los datos ejemplo de la tabla RevisionVivienda.




¿Identifico la anomalía en dicha tabla? ¿Aún no? Observe las visitas hecha el día 1-1-12 del empleado EACP, ahora imagine que ese día el empleado se equivocó al momento de registrar los datos, pues el no llevo el vehículo P1111, sino que utilizo para dichas visitas el carro Z2222. Si usted debe hacer esta corrección a los datos ¿cuantas tuplas tendría que modificar?



Ahí está el problema, debería, si el modelo fuera adecuado solo modificar una tupla, pero en lugar de ello, debe modificar en este caso 3 tuplas, a pesar que los Carros son asignados todo el día a un empleado.


Veamos paso a paso el proceso de normalización para la tabla RevisionVivienda y así solucionar la anomalía.

1FN:
            La tabla RevisionVivienda ya está en primera forma normal, posee una llave primaria, compuesta por el ID_Vivienda + Fecha y no tiene campos repetidos, importante es mencionar que una vivienda solo puede ser revisada una vez el mismo día, por ello se escogió esta llave primaria.

2FN:
            Veamos, esta cita que todos los campos que no son llave primaria, deben depender funcionalmente de toda la llave primaria, y no de una parte de ella, los campos ID_empleado, Observacion y Id_Carro, cumplen con esta condición, pues dependen de toda la llave primaria, no de una parte de ella.

3FN:
            Esta cita que aquellos campos que dependan transitivamente de la llave primaria por medio de otro campo, deben ser eliminados, veamos nuevamente los últimos 3 campos, ¿dependen transitivamente de otro campo? La respuesta es que NO, esta tabla si cumple la tercera forma normal.

Bueno y entonces qué pasa con nuestra anomalía, paso las primeras 3 formas normales. Para ello existe una solución, y es aplicar una tercera forma normal más fuerte, que se conoce como Boyce-Cod.

Forma Normal de Boyce-Codd:
            En forma sencilla cita, que debemos cumplir la condición que todo determinante en la tabla debe ser llave candidata, pues entonces veamos los determinantes que existen, y si alguno de ellos NO puede identificar de forma única una tupla, dicha dependencia funcional debe eliminarse de la tabla.

1Id_Vivienda + Fecha -> Id_empleado, Observacion, Id_Carro                   (llave primaria OK)
2Id_Vivienda + Id_Empleado + Fecha -> Observacion, Id_Carro                (llave candidata OK)
3Id_Empleado + Fecha -> Id_Carro                                                            ( Problema)

Observemos la tercera dependencia funcional, el Carro es asignado a un empleado en un día especifico, dicho empleado tendrá asignado todo el día ese carro para realizar sus visitas a las viviendas, pero esta dependencia funcional NO es una llave candidata de la relación, y ahí está el problema.

Para solucionarlo debemos tomar esta dependencia funcional y convertirla en otra tabla, de la cual será la llave primaria el determinante de la dependencia. La solución se muestra en la siguiente figura:


Noten que se quitó el campo Id_carro de la tabla RevisionVivienda, y se creó la nueva tabla AsignacionCarro.




Espero esta explicación les haya servido de mucho provecho, y como ven se ha explicado de manera sencilla y muy al grano, evitándonos horas y horas de leer páginas de un libro con muchos modelos matemáticos enredados. Esperamos en próximamente explicar la siguiente forma normal en otra dosis de normalidad.


¡Saludos!

lunes, abril 13, 2009

La importancia de los procedimientos almacenados

En esta ocasión, me quiero concentrar en algo muy importante del inmenso mundo (y misterioso para algunos) de las bases de datos, quiero hablarles de: Los Procedimientos Almacenados.
Los procedimientos almacenados (conocidos también como proc, sproc, stopro, o SP's por sus siglas en Ingles) son subrutinas que están disponibles para las aplicaciones que acceden a una base de datos relacional. Los procedimientos almacenados están, como su nombre lo indica, almacenados en el diccionario de datos de la base de datos.

¿Para que existen?, ¿para que usarlos, si puedo tener mis consultas bien bonitas metida en mi código (como consultas SQL Ad-hoc)? Esas preguntas exactas me hice yo hace algunos años. Que pena ser tan ingenuo. Gracias a Dios desperté de ese "lapsus ..." y si bien, no lo se todo, lo que se, lo tengo que compartir.

El uso más típico de los SP (de ahora en adelante asi me estaré refiriendo a ellos, en vez de escribir Procedimientos Almacenados) es proveer una validación integrada en la base de datos, asi como proveer mecanismos de control de acceso a la misma.
Los SP son usados para consolidar y centralizar lógica que originalmente se implementaba en las aplicaciones.
Eso quiere decir, que en vez de tener una "clase", con una lista interminable de funciones que hacen esto:
static function String getConsultaUsuario(String usuarioid) {
return "SELECT * FROM user WHERE userid = '" + usuarioid +"'";
}
...usted debería de tener una serie SP en su gestor de bases de datos, implementado como un API "consolidado y centralizado" (en la base de datos). Lo mismo sucede con muchas consultas SQL "grandes", o secuenciales: no podemos dejarlas regadas en el codigo, necesitamos moverlas a un solo lugar...

"MySQL también tiene procedimientos almacenados"

¿Por que? bien, enumerare solo algunas razones:
  • El mantenimiento de las consultas SQL es mas sencillo, porque las consultas SQL están centralizadas en el gestor.
  • La seguridad se enriquece utilizando SP's, debido a que un buen DBA (Administrador de Bases de Datos) únicamente proveerá una lista de procedimientos (bien tipificados y documentados) que el programador llamara de acuerdo a sus necesidades. Asi, relevamos al programador de preocuparse de verificar que los INSERT, DELETE, etc... estén "bien", lo aliviamos de la "carga" de manipular directamente la base de datos. Y dejamos esa lógica en donde debe de ir: en el gestor.
  • Suponga que debe añadir una condición extra a la función de ejemplo "getConsultaUsuario", tendrías que cambiar la cadena que se retorna en la función, probar los cambios, compilar o publicar tu aplicación. Los SP se pueden modificar, sin necesidad de recompilar y hacer un deploy completo de la aplicación.
  • Y lo más importante de todo, los procedimientos almacenados SIEMPRE serán más rapidos que una consulta externa. Si no lo son, es por dos motivos: a) No puedes escribir procedimientos almacenados, y/o b) El gestor de base de datos que estas usando es deficiente.
Entonces podemos observar dos ventajas inmediatas: Reducir la carga de mantenimiento de código SQL, y aumentar la velocidad de la aplicación.
La desventajas: Nos estaremos amarrando al gestor, y más de algún programador probablemente saltara por no poder "tocar" (manipular) directamente los datos en la BD. Esto no es necesariamente malo, pero más de alguno protestará.

Tengo que aclarar que no hay usar SP absolutamente todo el tiempo y en toda aplicación a desarrollar. Un caso practico para implementar SP en una aplicación, es en el que se tiene una sola base de datos, y diferentes módulos o clientes que se conectan constantemente a esta. ¿Se imaginan tener una lista de consultas en cada modulo o cliente que se conecta?, ¿Y si se modifica la base de datos?, ¿cuantas consultas y en cuantos lugares lo iremos a modificar?

"Los SP son parte de la Alquimia de SQL que usted debe conocer"

Los SP en general, serán realmente útiles (y aplicables) en caso de estar desarrollando aplicaciones robustas, de categoría empresarial, o para servicios que deben ser seguros, que posean alta disponibilidad y con vistas a ser escalables.

¿Y dónde aprendo, donde veo ejemplos, etc? ... como siempre, Google tiene la respuesta.
¿Y tú, estas utilizando Procedimientos Almacenados en tu Software?

La importancia de los procedimientos almacenados

En esta ocasión, me quiero concentrar en algo muy importante del inmenso mundo (y misterioso para algunos) de las bases de datos, quiero hablarles de: Los Procedimientos Almacenados.
Los procedimientos almacenados (conocidos también como proc, sproc, stopro, o SP's por sus siglas en Ingles) son subrutinas que están disponibles para las aplicaciones que acceden a una base de datos relacional. Los procedimientos almacenados están, como su nombre lo indica, almacenados en el diccionario de datos de la base de datos.

¿Para que existen?, ¿para que usarlos, si puedo tener mis consultas bien bonitas metida en mi código (como consultas SQL Ad-hoc)? Esas preguntas exactas me hice yo hace algunos años. Que pena ser tan ingenuo. Gracias a Dios desperté de ese "lapsus ..." y si bien, no lo se todo, lo que se, lo tengo que compartir.

El uso más típico de los SP (de ahora en adelante asi me estaré refiriendo a ellos, en vez de escribir Procedimientos Almacenados) es proveer una validación integrada en la base de datos, asi como proveer mecanismos de control de acceso a la misma.
Los SP son usados para consolidar y centralizar lógica que originalmente se implementaba en las aplicaciones.
Eso quiere decir, que en vez de tener una "clase", con una lista interminable de funciones que hacen esto:
static function String getConsultaUsuario(String usuarioid) {
return "SELECT * FROM user WHERE userid = '" + usuarioid +"'";
}
...usted debería de tener una serie SP en su gestor de bases de datos, implementado como un API "consolidado y centralizado" (en la base de datos). Lo mismo sucede con muchas consultas SQL "grandes", o secuenciales: no podemos dejarlas regadas en el codigo, necesitamos moverlas a un solo lugar...

"MySQL también tiene procedimientos almacenados"

¿Por que? bien, enumerare solo algunas razones:
  • El mantenimiento de las consultas SQL es mas sencillo, porque las consultas SQL están centralizadas en el gestor.
  • La seguridad se enriquece utilizando SP's, debido a que un buen DBA (Administrador de Bases de Datos) únicamente proveerá una lista de procedimientos (bien tipificados y documentados) que el programador llamara de acuerdo a sus necesidades. Asi, relevamos al programador de preocuparse de verificar que los INSERT, DELETE, etc... estén "bien", lo aliviamos de la "carga" de manipular directamente la base de datos. Y dejamos esa lógica en donde debe de ir: en el gestor.
  • Suponga que debe añadir una condición extra a la función de ejemplo "getConsultaUsuario", tendrías que cambiar la cadena que se retorna en la función, probar los cambios, compilar o publicar tu aplicación. Los SP se pueden modificar, sin necesidad de recompilar y hacer un deploy completo de la aplicación.
  • Y lo más importante de todo, los procedimientos almacenados SIEMPRE serán más rapidos que una consulta externa. Si no lo son, es por dos motivos: a) No puedes escribir procedimientos almacenados, y/o b) El gestor de base de datos que estas usando es deficiente.
Entonces podemos observar dos ventajas inmediatas: Reducir la carga de mantenimiento de código SQL, y aumentar la velocidad de la aplicación.
La desventajas: Nos estaremos amarrando al gestor, y más de algún programador probablemente saltara por no poder "tocar" (manipular) directamente los datos en la BD. Esto no es necesariamente malo, pero más de alguno protestará.

Tengo que aclarar que no hay usar SP absolutamente todo el tiempo y en toda aplicación a desarrollar. Un caso practico para implementar SP en una aplicación, es en el que se tiene una sola base de datos, y diferentes módulos o clientes que se conectan constantemente a esta. ¿Se imaginan tener una lista de consultas en cada modulo o cliente que se conecta?, ¿Y si se modifica la base de datos?, ¿cuantas consultas y en cuantos lugares lo iremos a modificar?

"Los SP son parte de la Alquimia de SQL que usted debe conocer"

Los SP en general, serán realmente útiles (y aplicables) en caso de estar desarrollando aplicaciones robustas, de categoría empresarial, o para servicios que deben ser seguros, que posean alta disponibilidad y con vistas a ser escalables.

¿Y dónde aprendo, donde veo ejemplos, etc? ... como siempre, Google tiene la respuesta.
¿Y tú, estas utilizando Procedimientos Almacenados en tu Software?

domingo, agosto 24, 2008

Aprender ACCESS ¿para qué?...

Realmente no entiendo, ¿para que enseñan Access en las Universidades?.
Creo sinceramente (y si me equivoco, pueden dejar los comentarios para intentar convencerme) que la única forma de que una persona tenga una experiencia "agradable" con Access, es que seas un novato absoluto con las bases de datos o un usuario común y silvestre.
Access es a SQL lo que VBA es para VB.NET
Muchos desarrolladores (Salvadoreños al menos) estarán pensando en que Access es "bueno" para sistemas sencillos que necesitan bases de datos pequeñas. La respuesta a eso, es NO.
Permitanme explicarles: Microsoft Access utiliza un modulo de acceso a datos llamado Microsoft JET. Las siglas JET significan: Joint Engine Technology, el sucesor de esta tecnología fue primero MSDE (Microsoft Desktop Engine) y este, a su vez, fue sucedido por SQL Server 2005 Express y recientemente en el SQL Server 2005 Compact Edition.

"Guía del programador de JET"

Desde un punto de vista tecnológico: JET es considerado como una tecnologia desfazada por Microsoft. Es más, JET ya no se distribuye con la ultima versión de MDAC (Microsoft Data Access Components). Sin embargo, JET sigue siendo el motor de bases de datos de Microsoft Access 2007 y lo seguirá hasta el fin de los tiempos (o hasta que decidan cambiarlo). ¿Comprenden ahora en problema?
¿Cual es la "enseñanza" de utilizar un programa con una base tecnológica desfasada?
Sin mencionar el común problema, que las bases de datos tienen un limite de 2GB de capacidad. Tal parece que algunas personas desean enseñar los principios fundamentales de la creación de bases de datos relacionales (normalización, integridad referencial, etc...) utilizando Microsoft Access... es ridículo.

"¿Por qué enseñan software que apesta?"

¿Como se soluciona este problema? Utilizando herramientas reales de desarrollo. En vez de gastar dinero en licencias (si es que lo gastan) de Microsoft Office 2007, se recomienda usar SQL Server 2005 Express para este propósito. Y si lo que les gusta de Access, es que pueden elaborar bases de datos de forma gráfica, entonces usen: SQL Server 2005 Management Studio Express, que les permitir hacer exactamente lo mismo. Ambas herramientas son "freeware", se pueden descargar sin cargo alguno, se pueden redistribuir sin problemas de licencias y, por experiencia personal, es lo suficientemente sencillo para que cualquiera lo use. Y si están pensando en bases de datos portables, rápidas y sin limites de tamaño, piensen en alternativas libres como: SQLite y Apache Derby.

"SQLite es la solución a los problemas de bases de datos portables"

Yo use Access con VB 6.0, y desde entonces me propuse no contaminar mi mente nunca más con ese tipo de "soluciones informáticas", y claro, estoy arrepentido de haberlo usado, jaja. Y tu: ¿alguna vez utilizaste Access para desarrollar Software?

Aprender ACCESS ¿para qué?...

Realmente no entiendo, ¿para que enseñan Access en las Universidades?.
Creo sinceramente (y si me equivoco, pueden dejar los comentarios para intentar convencerme) que la única forma de que una persona tenga una experiencia "agradable" con Access, es que seas un novato absoluto con las bases de datos o un usuario común y silvestre.
Access es a SQL lo que VBA es para VB.NET
Muchos desarrolladores (Salvadoreños al menos) estarán pensando en que Access es "bueno" para sistemas sencillos que necesitan bases de datos pequeñas. La respuesta a eso, es NO.
Permitanme explicarles: Microsoft Access utiliza un modulo de acceso a datos llamado Microsoft JET. Las siglas JET significan: Joint Engine Technology, el sucesor de esta tecnología fue primero MSDE (Microsoft Desktop Engine) y este, a su vez, fue sucedido por SQL Server 2005 Express y recientemente en el SQL Server 2005 Compact Edition.

"Guía del programador de JET"

Desde un punto de vista tecnológico: JET es considerado como una tecnologia desfazada por Microsoft. Es más, JET ya no se distribuye con la ultima versión de MDAC (Microsoft Data Access Components). Sin embargo, JET sigue siendo el motor de bases de datos de Microsoft Access 2007 y lo seguirá hasta el fin de los tiempos (o hasta que decidan cambiarlo). ¿Comprenden ahora en problema?
¿Cual es la "enseñanza" de utilizar un programa con una base tecnológica desfasada?
Sin mencionar el común problema, que las bases de datos tienen un limite de 2GB de capacidad. Tal parece que algunas personas desean enseñar los principios fundamentales de la creación de bases de datos relacionales (normalización, integridad referencial, etc...) utilizando Microsoft Access... es ridículo.

"¿Por qué enseñan software que apesta?"

¿Como se soluciona este problema? Utilizando herramientas reales de desarrollo. En vez de gastar dinero en licencias (si es que lo gastan) de Microsoft Office 2007, se recomienda usar SQL Server 2005 Express para este propósito. Y si lo que les gusta de Access, es que pueden elaborar bases de datos de forma gráfica, entonces usen: SQL Server 2005 Management Studio Express, que les permitir hacer exactamente lo mismo. Ambas herramientas son "freeware", se pueden descargar sin cargo alguno, se pueden redistribuir sin problemas de licencias y, por experiencia personal, es lo suficientemente sencillo para que cualquiera lo use. Y si están pensando en bases de datos portables, rápidas y sin limites de tamaño, piensen en alternativas libres como: SQLite y Apache Derby.

"SQLite es la solución a los problemas de bases de datos portables"

Yo use Access con VB 6.0, y desde entonces me propuse no contaminar mi mente nunca más con ese tipo de "soluciones informáticas", y claro, estoy arrepentido de haberlo usado, jaja. Y tu: ¿alguna vez utilizaste Access para desarrollar Software?

miércoles, agosto 06, 2008

No hay internet? usa Gears!

Continuando con la saga de posts para los adictos al Internet, especialmente cuando no sabemos que hacer cuando este nos falla, ahora Google nos brinda una nueva alternativa para no perdernos de sus servicios cuando sucedan estos casos tan trágicos como la falta de Internet.

"Logotipo de Google Gears"

Esta alternativa se llama Google Gears, una tecnología que almacena la información on-line de los servicios que lo implementan en una base de datos en la computadora del usuario, de forma que sea posible seguir usando estos servicios aunque no estemos conectados a Internet.

Para usar Gears, basta con ir a la página principal de este servicio, el cual te instalara el Add-on de Firefox (así es, funciona nada mas con el mejor navegador del mercado: Firefox) que permitirá revisar dichos documentos sin la necesidad de una conexión a Internet.

Una vez instalado, nada más visiten los sitios que permiten el uso de Gears para que guarden su información on-line de forma local en su computadora. Por ejemplo, en Google Docs les aparecerá junto a su dirección de correo electrónico un vínculo con la palabra "Offline" (Deben configurarlo para el lenguaje Ingles, por cierto):


"Mensaje que indica que ahora podemos configurar Google Docs para trabajar sin conexión (Clic para agrandar)."

Al hacer clic en este vinculo, aparece un mensaje de confirmación para configurar el acceso sin conexión a Google Documents. Al confirmar nuestra decisión, aparecerá otro cuadro de diálogo por parte de Gears, preguntándonos si queremos darle acceso a Google Documents de usar su API. Al confirmar también este cuadro, automáticamente empieza a sincronizar la base de datos local con la información on-line, en este caso, a copiar los documentos que tenemos en nuestra cuenta de Google Documents a una base de datos alojada en nuestra computadora:


"Google Gears, sincronizando los documentos on-line con nuestra base de datos local (Clic para agrandar)."

Al terminar la sincronización, ya esta todo preparado para poder trabajar sin conexión. Simplemente llamen a su ISP y díganles que no quieren mas el servicio de Internet, consigan unas tijeras y corten el cable UTP, quiebren su tarjeta de red o si no quieren ser tan drásticos, nada mas hagan clic en la opción "Work Offline" ("Trabajar sin Conexión" en español) del menú archivo de Firefox para que puedan comprobar que la pagina les seguirá cargando, permitiéndoles visualizar y editar sus documentos de Google Documents.

Entre los servicios que actualmente soportan Gears están:

  • Google Reader: Lector on-line de Feeds RSS/Atom que te mantiene actualizado de la ultima información publicada en las revistas/blogs de tu interés. Link.
  • Google Docs: Como ya lo vimos en el ejemplo, es toda una suite de oficina on-line que permite crear/subir/editar/publicar documentos de texto, hojas de cálculo, presentaciones y documentos PDF. Soporta los formatos comunes de MS Office y OpenOffice. Link.
  • Remember The Milk: Servicio del web que nos permite almacenar recordatorios de cosas que tenemos que hacer (por eso su nombre: acuérdate de la leche!). Ademas, esta enriquecido con la capacidad de ubicar el lugar donde se realizara la tarea mediante mapas de Google Maps y establecer la fecha/hora/duración de la actividad, sincronizable vía CalDaV. Link.
  • Zoho: La competencia de Google en cuanto a suite de oficina on-line. Entre otras cosas también permite el uso de su servicio de chat, cuentas de correo, wikis, gestores de proyectos, etc. Link.

No hay internet? usa Gears!

Continuando con la saga de posts para los adictos al Internet, especialmente cuando no sabemos que hacer cuando este nos falla, ahora Google nos brinda una nueva alternativa para no perdernos de sus servicios cuando sucedan estos casos tan trágicos como la falta de Internet.

"Logotipo de Google Gears"

Esta alternativa se llama Google Gears, una tecnología que almacena la información on-line de los servicios que lo implementan en una base de datos en la computadora del usuario, de forma que sea posible seguir usando estos servicios aunque no estemos conectados a Internet.

Para usar Gears, basta con ir a la página principal de este servicio, el cual te instalara el Add-on de Firefox (así es, funciona nada mas con el mejor navegador del mercado: Firefox) que permitirá revisar dichos documentos sin la necesidad de una conexión a Internet.

Una vez instalado, nada más visiten los sitios que permiten el uso de Gears para que guarden su información on-line de forma local en su computadora. Por ejemplo, en Google Docs les aparecerá junto a su dirección de correo electrónico un vínculo con la palabra "Offline" (Deben configurarlo para el lenguaje Ingles, por cierto):


"Mensaje que indica que ahora podemos configurar Google Docs para trabajar sin conexión (Clic para agrandar)."

Al hacer clic en este vinculo, aparece un mensaje de confirmación para configurar el acceso sin conexión a Google Documents. Al confirmar nuestra decisión, aparecerá otro cuadro de diálogo por parte de Gears, preguntándonos si queremos darle acceso a Google Documents de usar su API. Al confirmar también este cuadro, automáticamente empieza a sincronizar la base de datos local con la información on-line, en este caso, a copiar los documentos que tenemos en nuestra cuenta de Google Documents a una base de datos alojada en nuestra computadora:


"Google Gears, sincronizando los documentos on-line con nuestra base de datos local (Clic para agrandar)."

Al terminar la sincronización, ya esta todo preparado para poder trabajar sin conexión. Simplemente llamen a su ISP y díganles que no quieren mas el servicio de Internet, consigan unas tijeras y corten el cable UTP, quiebren su tarjeta de red o si no quieren ser tan drásticos, nada mas hagan clic en la opción "Work Offline" ("Trabajar sin Conexión" en español) del menú archivo de Firefox para que puedan comprobar que la pagina les seguirá cargando, permitiéndoles visualizar y editar sus documentos de Google Documents.

Entre los servicios que actualmente soportan Gears están:

  • Google Reader: Lector on-line de Feeds RSS/Atom que te mantiene actualizado de la ultima información publicada en las revistas/blogs de tu interés. Link.
  • Google Docs: Como ya lo vimos en el ejemplo, es toda una suite de oficina on-line que permite crear/subir/editar/publicar documentos de texto, hojas de cálculo, presentaciones y documentos PDF. Soporta los formatos comunes de MS Office y OpenOffice. Link.
  • Remember The Milk: Servicio del web que nos permite almacenar recordatorios de cosas que tenemos que hacer (por eso su nombre: acuérdate de la leche!). Ademas, esta enriquecido con la capacidad de ubicar el lugar donde se realizara la tarea mediante mapas de Google Maps y establecer la fecha/hora/duración de la actividad, sincronizable vía CalDaV. Link.
  • Zoho: La competencia de Google en cuanto a suite de oficina on-line. Entre otras cosas también permite el uso de su servicio de chat, cuentas de correo, wikis, gestores de proyectos, etc. Link.

miércoles, mayo 14, 2008

3 reglas al trabajar con Bases de Datos

Aquí presento algunas reglas para trabajar con bases de datos:

Regla 1: Nunca uses un solo servidor de bases de datos para todo el trabajo de desarrollo (exacto, nada de bases de datos centralizadas).

La conveniencia de trabajar con un servidor centralizado de bases de datos es tentadora. Todos los desarrolladores se conectan a una sola base de datos que pueden probar y cambiar. Este servidor funcionara como el Anillo Único de Sauron... y todos los cambios que se den, se reflejaran inmediatamente a todos los miembros del equipo de desarrollo. Es más, es tan convincente la idea de usar un servidor centralizado, que este la gente lo usa como repositorio de datos de prueba.

"Imagen: Gollum con el Anillo"

Pero, como muchas conveniencias en el desarrollo de software (y así de engañoso y malévolo como el Anillo Único), usar una sola base de datos para todo el equipo, funciona como un pozo de brea... si, como en el que murieron tantos dinosaurios :P.

"Imagen: Pozo de Brea"

Todos los desarrolladores están tentados a cambiar los tipos de datos en algún momento, y los mas probable es que así sea, pero el cambio que un desarrollador puede hacer en la base de datos... veamos que sucede, cuando todo sale mal... estos son los pasos al pozo de brea:
  1. Un desarrollador modifica un tipo de dato en la base de datos (o peor, una tabla entera... o varias).
  2. El cambio probablemente provocara un error en mi código (ya no puedo compilar mi parte).
  3. Esto implica que tengo que hacer cambios en mi código para que todo funciona como antes.
  4. O tengo que esperar a que el desarrollador que modifico la base de datos haga un "Commit" de su código para que altere el mio... y ver si funciona con lo que el hizo.
  5. Pueda que su "Commit" altere o no mi código.
  6. Si no lo altera, y ahora YO tendré que ver que $%&&/$ altero el tipo, para que mi código funcione (¿cuanto tiempo perdí ya?).
  7. Es posible también que el tipo diga después: "bueno, me equivoque, solo estaba probando...".
  8. Ahora hay que regresar a la versión anterior del software, perder horas de cambios y ajustes, y realizar el proceso, cada vez que alguien disponga hacer el paso 1.
Ademas desarrollar con una base de datos remota es LENTOOOOOOO...

"Imagen: Maldito desarrollador, ¡cambiaste todas las tablas sin avisar!"


Regla 2: Siempre ten una sola y respetada fuente para el esquema de tu base de datos (alguien se encarga de mantener y liberar la base de datos para todos).

Idealmente, esta única fuente sera tu control de versiones ( ver la regla #3). Considere el siguiente entre dos desarrolladores, Pedro y Juan:

Pedro: Es tiempo para comenzar a probar la aplicación, y depurar los errores. ¿Copiamos la base de datos de la maquina de José, o usamos la base de datos de Luis?

Juan: Ummmmmmmm, no recuerdo cual es la base de datos mas reciente (u oficial, o actualizada)

Pedro: Shit... (se pone a llorar).

Todo mundo debería de saber donde esta el ultimo esquema de la base de datos, y también es el derecho de los desarrolladores tener una experiencia sin problema para obtenerla y usarla en su maquina de trabajo. Yo desarrollador quiero caminar a mi estación de trabajo, obtener la ultima versión de la base de datos por medio de cvs ó svn, y trabajar transparentemente con ella, sin preocuparme por nada más que hacer mi trabajo.


Regla 3: Siempre versiona tu base de datos.

Hay muchas maneras de versionar una base de datos, pero el objetivo principal es propagar los cambios, probar y liberar la base de datos en una manera controlada y consistente. Un segundo objetivo es poder regresar y recrear la base de datos de algún momento anterior. Este segundo objetivo es particularmente importante si se produce software para clientes. Si alguien tiene un bug (error) en la versión 1.00.3.4 de tu aplicación (y tu vas por la versión 2.00.5.0) tienes que ser capaz de recrear la aplicación y su base de datos para esa versión, para poder darle soporte técnico al cliente o a los clientes que tengan esa versión.

Respeta estas reglas, y tu desarrollo de software sera muchísimo mas sencillo y menos traumatico.

¡Saludos!


3 reglas al trabajar con Bases de Datos

Aquí presento algunas reglas para trabajar con bases de datos:

Regla 1: Nunca uses un solo servidor de bases de datos para todo el trabajo de desarrollo (exacto, nada de bases de datos centralizadas).

La conveniencia de trabajar con un servidor centralizado de bases de datos es tentadora. Todos los desarrolladores se conectan a una sola base de datos que pueden probar y cambiar. Este servidor funcionara como el Anillo Único de Sauron... y todos los cambios que se den, se reflejaran inmediatamente a todos los miembros del equipo de desarrollo. Es más, es tan convincente la idea de usar un servidor centralizado, que este la gente lo usa como repositorio de datos de prueba.

"Imagen: Gollum con el Anillo"

Pero, como muchas conveniencias en el desarrollo de software (y así de engañoso y malévolo como el Anillo Único), usar una sola base de datos para todo el equipo, funciona como un pozo de brea... si, como en el que murieron tantos dinosaurios :P.

"Imagen: Pozo de Brea"

Todos los desarrolladores están tentados a cambiar los tipos de datos en algún momento, y los mas probable es que así sea, pero el cambio que un desarrollador puede hacer en la base de datos... veamos que sucede, cuando todo sale mal... estos son los pasos al pozo de brea:
  1. Un desarrollador modifica un tipo de dato en la base de datos (o peor, una tabla entera... o varias).
  2. El cambio probablemente provocara un error en mi código (ya no puedo compilar mi parte).
  3. Esto implica que tengo que hacer cambios en mi código para que todo funciona como antes.
  4. O tengo que esperar a que el desarrollador que modifico la base de datos haga un "Commit" de su código para que altere el mio... y ver si funciona con lo que el hizo.
  5. Pueda que su "Commit" altere o no mi código.
  6. Si no lo altera, y ahora YO tendré que ver que $%&&/$ altero el tipo, para que mi código funcione (¿cuanto tiempo perdí ya?).
  7. Es posible también que el tipo diga después: "bueno, me equivoque, solo estaba probando...".
  8. Ahora hay que regresar a la versión anterior del software, perder horas de cambios y ajustes, y realizar el proceso, cada vez que alguien disponga hacer el paso 1.
Ademas desarrollar con una base de datos remota es LENTOOOOOOO...

"Imagen: Maldito desarrollador, ¡cambiaste todas las tablas sin avisar!"


Regla 2: Siempre ten una sola y respetada fuente para el esquema de tu base de datos (alguien se encarga de mantener y liberar la base de datos para todos).

Idealmente, esta única fuente sera tu control de versiones ( ver la regla #3). Considere el siguiente entre dos desarrolladores, Pedro y Juan:

Pedro: Es tiempo para comenzar a probar la aplicación, y depurar los errores. ¿Copiamos la base de datos de la maquina de José, o usamos la base de datos de Luis?

Juan: Ummmmmmmm, no recuerdo cual es la base de datos mas reciente (u oficial, o actualizada)

Pedro: Shit... (se pone a llorar).

Todo mundo debería de saber donde esta el ultimo esquema de la base de datos, y también es el derecho de los desarrolladores tener una experiencia sin problema para obtenerla y usarla en su maquina de trabajo. Yo desarrollador quiero caminar a mi estación de trabajo, obtener la ultima versión de la base de datos por medio de cvs ó svn, y trabajar transparentemente con ella, sin preocuparme por nada más que hacer mi trabajo.


Regla 3: Siempre versiona tu base de datos.

Hay muchas maneras de versionar una base de datos, pero el objetivo principal es propagar los cambios, probar y liberar la base de datos en una manera controlada y consistente. Un segundo objetivo es poder regresar y recrear la base de datos de algún momento anterior. Este segundo objetivo es particularmente importante si se produce software para clientes. Si alguien tiene un bug (error) en la versión 1.00.3.4 de tu aplicación (y tu vas por la versión 2.00.5.0) tienes que ser capaz de recrear la aplicación y su base de datos para esa versión, para poder darle soporte técnico al cliente o a los clientes que tengan esa versión.

Respeta estas reglas, y tu desarrollo de software sera muchísimo mas sencillo y menos traumatico.

¡Saludos!


Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...