Virtual Consulting Magazine

Luego de trabajar con costosas configuraciones de SQL Server y Oracle la gran mayoría de mi carrera profesional, casi siempre defendiendo estas alternativas de forma “viciada” a capa y espada es difícil abrir los ojos y ver otras opciones, especialmente por esa “propaganda” que apoya la idea (ahora extinta) que: SQL Server y/o Oracle son (o fueron) las mejores elecciones o alternativas de base de datos para la organización. Y creo que muchos solemos ser los “abogados” de las bases de datos comerciales.

Tal vez, estas bases de datos nos han dado de comer durante muchos años, no hay duda, incluso seamos profesionales, tal vez no expertos, pero sí profesionales en el manejo de estos motores, que muchas veces hemos tratado a los demás como “herejes”  por no aceptar “la verdad”. Y así como hay profesionales “adictos” a estas bases de datos también, están quienes les guardan distancia por distintas razones.

¿MySQL? Por favor, ¿se están burlando?. ¿PostgreSQL?, Gracias, aunque es en proyecto serio, necesitamos una base de datos de la que podamos depender y confiar.

Suenan familiares las frases anteriores, ¿verdad?.

¿Cuántas veces hemos llevado a cabo algún “análisis” para determinar si, de hecho, SQL Server y/o Oracle eran las mejores elecciones no para mí, sino para el equipo, el cliente, el empleador y la organización?

0

Y si hemos realizado con diligencia esos análisis, ¿Qué hemos aprendido? Dos cosas:

• SQL Server y Oracle son realmente bases de datos excelentes. (Está bien, eso ya lo sabíamos.)
• SQL Server y Oracle son una elección errónea para el 95% de las necesidades de almacenamiento de datos, incluso a nivel empresarial.

Hoy en día, es agradable pensar en SQL Server y Oracle como las Estrellas de la muerte del universo de las bases de datos relacionales (para decirlo en términos de la Guerra de las Galaxias), es decir, extremadamente poderosas, monolíticas, brillantes, complejas casi más allá de la comprensión que una simple mente humana pueda llegar a tener, y que significan un gasto monumental de dinero excepto en esas raras situaciones cuando se necesita destruir un planeta.

He podido ver (al menos) a una docena de compañías derrochando dinero en bases de datos que no necesitan, impactando y confundiendo sus balances finales con esquemas de licencias que adornan las oficinas, perpetuando así la Falacia del Software de Marca:

En igualdad de condiciones, y asumiendo que se tiene el presupuesto, generalmente se prefiere un costoso (por no decir caro) bien “ajustado” producto comercial como [inserte el producto comercial aquí] a análogos más económicos [inserte producto open-source o de precio razonable aquí]. Los desarrolladores del proyecto XYZ usaron [costoso producto comercial], nuestro XYZ  interno usa [producto comercial costoso], ergo, nueva política de la compañía: se utiliza [producto comercial costoso]. Claro, a $89,000 por licencia, [producto comercial costoso] es un poco costoso, pero a quién estamos engañando? Gastamos [inserte un monto realmente ridículo de  dinero solo disponible en Monopoly aquí] en IT cada año.

Está bien claro, se ha gastado una cantidad ridícula de dinero en IT. Alguna vez se ha preguntado por qué?

Veamos el siguiente ejemplo en este cuadro (Está inglés pero creo que es bastante claro):

Por qué comprometer su proyecto, su organización, su imperio, para construir y mantener una “Estrella de la Muerte” cuando lo que realmente necesita es una nave X-Wing, un AT-AT, o por mucho, un Destructor de Estrellas? Especialmente dado que:

• El rendimiento y desempeño de una instalación Firebird/PostgreSQL/MySQL puede perfectamente ser rival de SQL Server y Oracle.
• La gran mayoría de aplicaciones no necesita las capacidades de las últimas, grandes y majestuosas versiones de las base de datos de Microsoft y Oracle .
• Firebird SQL, PostgreSQL y MySQL son 100% gratis (en el caso de MySQL hay una versión comercial) lo que significa que, sí eso mismo, no más fatalidad económica a  causa de licencias comerciales. (Claro, cabe mencionar que Oracle ahora es dueño de Sun y por ende controla a MySQL.)

Oracle y SQL Server tiene características más potentes que MySQL o PostgreSQL o Firebird o cualquier otra base de datos de código abierto. Tienen una funcionalidad más integrada. Nadie podría afirmar lo contrario. Pero son los desarrolladores y DBAs y las personas que toman las decisiones de compra totalmente conscientes (por ejemplo) tan solo de cuán ricas y poderosas son las características técnicas de PostgreSQL?

Una base de datos de clase empresarial, PostgreSQL cuenta con sofisticadas funciones como el control de concurrencia multi-versión  (MVCC), puntos de restauración en el tiempo, tablespaces, replicación asincrónica, transacciones anidadas (savepoints), copias de seguridad en línea/en caliente, un sofisticado analizador/optimizador de consultas, y un sistema write ahead para la tolerancia a fallos. Es compatible con conjuntos de caracteres internacionales, codificación de caracteres multibyte, Unicode, y tiene en cuenta la configuración regional para el ordenamiento, sensibilidad a mayúsculas y minúsculas, y formateo. Es altamente escalable, tanto en la enorme cantidad de datos que puede manejar como en el número de usuarios concurrentes que puede gestionar. Hay sistemas PostgreSQL activos en entornos de producción que manejan 4 terabytes de datos sin problemas.

Dejando las configuraciones de PostgreSQL a un lado, están los desarrolladores conscientes de que MySQL tiene más 11 millones de instalaciones incluyendo gigantes tales como Facebook, YouTube, Flickr, y Wikipedia? Claro, Todo el mundo lo sabe. MySQL se ejecuta en la web, cierto? Entonces, realmente necesitamos el soporte de visualización hiper-cúbica cuatri-dimensional de las bases de datos comerciales cuando las necesidades en datos de la mayoría de organizaciones es modesta, y cuando las dos o tres bases de datos de código abierto han comprobado repetidamente sus capacidades y temple?

No.

No a menos que su necesidad pertenezca al 1% de los escenarios, aprovechando las características únicas de las bases de datos propietarias Oracle/SQL Server. (En tal caso, puede que tenga otro tipo de problema.)

De lo contrario la respuesta es simplemente: no.

Pero no permita que eso lo detenga! Por todo los medios, si usted está en un contrato gubernamental sobrecosteado donde desperdiciar dinero es fomentado, adelante y despréndase de ese dinero que le hace tanto estorbo y adquiera una de esas costosas bases de datos cerradas. Si cuando Microsoft o Oracle dicen “salte!” su organización dice “qué tan alto?”, prosiga y cierre el trato adquiriendo esa licencia costosa de plataforma “superior”. Si su organización está dominada por un montón de bocones aspirantes a evagelistas de tecnología que llevan a cabo una agenda personal, como generalmente es el caso, entonces probablemente no hay mucho que usted pueda hacer en este caso.

Pero si ud cuida el dinero, si cree que…

No! NO está bien desperdiciar una cuarto de millón de dólares al año en licencias de bases de datos a pesar de que el presupuesto IT esté en decenas de millones…

… y si tiene actualmente tiene el poder para influenciar sobre las decisiones de compra, entonces utilice bases de datos de código abierto siempre que le sea posible, y bases de datos comerciales cuando absolutamente deba hacerlo.

Su CFO (Director Financiero) se lo agradecerá.*

* – Bueno, probablemente no. Así es la vida.

Traducido y Adaptado de Coding The Wheel

¿Porqué tan pocos desarrolladores están usando Firebird SQL? Ha sido la pregunta formulada por Henrique Lobo en su blog iTexto concluyendo que pensar que no hay muchos desarrolladores es estar en un gran error, pues hay más desarrolladores que utilizan Firebird de los que se cree y este número está creciendo rápidamente; los desarrolladores se están dando cuenta de las ventajas que éste motor tiene frente a otras bases de datos como MySQL: el principal “competidor”.

A primera vista, pareciera que quienes usan Firebird son los desarrolldores en Delphi. Aunque el número de desarrolladores usando este motor va en aumento sigue siendo reducido, ¿por qué no es tan popular como MySQL o PostgreSQL? Tal vez como se indica en el sitio de Firebird SQL:

Como probablemente algunos hayan notado, Firebird es más maduro, tienen más características, no vale ni un centavo y es seguro que está más preparada para ambientes empresariales. Entonces, ¿por qué no hay muchas personas que hayan escuchado de este motor?

Las razones son simples:

1. Firebird no tiene una única entidad comercial que gestione el desarrollo y gane dinero por ello. Hay compañías, pero ninguna de ellas obtienen ganancias por vender licencias de Firebird (Firebird es totalmente gratis). Esas empresas venden soporte pero el retorno económico es mucho menor.

Por lo tanto, no hay nadie que invierta su dinero en mercadeo y haga un despliegue alrededor de este proyecto. Problemas similar es plagan a otros proyectos de código abierto como PostgreSQL, por ejemplo.

2. Cuando fue el boom de los servidores web y las aplicaciones web, Firebird no estaba listo para ser una base de datos para web. Como la demanda por almacenamiento de datos creció, la gente estuvo demandando algo más fácil y rápido que archivos planos del tipo Perl. MySQL, simplemente estuvo en el lugar correcto en el momento correcto. Al poco tiempo, cada ISP (Proveedor de internet) tenía soporte para PHP y MySQL y la plataforma LAMP fue aceptada. Como suele suceder, esos primeros en un mercado nuevo, rápidamente fueron aceptados, y es bastante difícil para otros dejar que esa “tajada” de mercado se vaya.

Tal vez sea una situación injusta, pero muchos desarrolladores han empezado a reconsiderarla. Pero acaso ¿qué características tiene este motor que merezca la atención de los desarrolladores? Bueno, helas a continuación:

• Realmente gratuito: contrario a MySQL, Firebird i puede ser usado en aplicativos comerciales sin ningún tipo de “honorarios” o problemas legales. (Cabe mencionar que PostgreSQL tiene esa ventaja también)
• Todas las características básicas de los grandes RDBMS: Procedimientos almacenados, disparadores o triggers, A.C.I.D., copias de seguridad en caliente, generadores, integridad referencial, y un gran etc.
• Bajo consumo de recursos: ¿Alguna vez ha visto una base de datos embebida? Simplemente sorprendente: en menos de 1 MB se podrá disponer de todas las características de la base de datos sin “cortarle” nada!
• Bajos requerimientos de hardware: básicamente, si algo realiza operaciones informáticas, de seguro podrá correr Firebird.
• Disponible en todas las grandes plataformas: Linux, Windows, Mac OS, Solaris y otras.
• Rendimiento razonable: El rendimiento de Firebird está al igual del prestado por MySQL y PostgreSQL.
• Proyecto bastante activo: a pesar de su baja popularidad, s un proyecto bastante activo. Por ejemplo, en abril de 2009, se anunció la beta de la versión 2.5 del proyecto.
• Bases de datos de tamaño ilimitado: El límite del tamaño de la base de datos está determinado por el sistema de archivos en el cual se almacena la base de datos. Pero, por si acaso, la base de datos excede el límite, siempre es posible dividirla en múltiples archivos. (La base de datos más grande conocida ocupa más de 980 GB)
• Compatibilidad 100% con el estándar SQL 92
  
• Conectividad: puede acceder a Firebird SQL a través de cualquier lenguaje de programación.

Y si hablamos de herramientas para administrar Firebird existen varias. Tanto así que también existe un programa que sirve para convertir de MS Access a Firebird.

Aunque es una base de datos para “enamorarse” y usar a diario, a veces es difícil que un cliente le dé tanta aceptación frente a MySQL o PostgreSQL. Otras razones que se podrían contemplar por lo que Firebird es tan impopular son:

• Por ahora, ninguna gran empresa presta soporte como Sun/Oracle o IBM.
• El sitio oficial (http://www.firebirdsql.org) no luce atractivo gráficamente, así que la primera impresión no suele ser la mejor. Cualquiera pensaría que está abandonado. El patrocinador más grande hoy en hoy en día es IBPhoenix , y su principal negocio es Firebird. Pero incluso su propio sitio web (el de IBPhoenix) cae en el mismo problema de diseño gráfico.
• El hecho de que siempre se ha asociado con Delphi desde un principio ha producido que con la decadencia de Delphi, la popularidad de Firebird también lucha por mantenerse a flote.
• Documentación escasa. Es difícil encontrar documentación y en castellano aún más.

Sea como sea, es un proyecto que promete bastante y que considero que esa racha de “injusticia” pasará y logrará posicionarse y darse a conocer. Pruébelo usted mismo y muy probablemente diga como yo: “Por qué no lo conocí antes”.

Hace poco leía el blog de Consultor Anónimo un post sobre un blog empresarial en donde su autor señala algo delicado que lo impulsó a hacer un alto en el camino y suspender temporalmente la publicación de nuevas entradas ya que podía generar “descontrol en la empresa”.

Diego Marino es consultor de la empresa Abiquo, y en su blog Externalidades imprime sus “sentimientos” y experiencias en su organización, según como lo indica en su blog:

Este blog surgió para contar “realmente” de que iba eso de montar una startup. Harto de leer autobombos de “hacemos, crecemos, ampliamos…” y demás falacias, pensé que tendría algún interés contar la realidad. La de verdad. La de los días buenos y la de los días malos [...] El problema viene cuando eso puede suponer algún problema a la empresa. Y ese es el momento de parar y reflexionar. Lo siento, pero me importa más la “imagen” de abiquo, que vuestras ganas de leer vivencias de primera mano

Al leer y notar la preocupación de Diego por la imagen de su empresa viene la pregunta: ¿Qué tan convenientes son los blogs empresariales?, ¿Qué tan saludable es para la imagen de la empresa decir la verdad y solo la verdad?, ¿Hasta qué punto la percepción negativa de un empleado es realmente negativa?, ¿La privacidad de la organización, sus estrategias y modus operandi están siendo publicados indiscriminadamente?, y otras preguntas que empiezan a cabilar en nuestras mentes.

Algo que en principio puede lucir como “publicidad gratuita” para la organización podría llegar a convertirse en un arma de doble filo. Todos somos conscientes que toda organización tiene sus momentos vigorosos y de prosperidad, y otros de desavenencias y vicisitudes, pero es claro que algunos “detalles” negativos podrían perjudicar la imagen de la organización.

Según Daniel, suspende su blog por “descontrol”, pero ¿es realmente descontrol?, tal vez, pero entonces si deseo publicar un blog con lo bueno, lo malo y lo feo del diario en la organización, ¿para qué presentar una imagen que no se tiene?. La cuestión es que cada vez que a alguien se le ocurra la idea de publicar un “diario en la empresa” debe medir el riesgo y la exposición que se desea tener al momento de publicar lo sucedido.

Sea como sea, amarillistas o no, somos humanos, cometemos errores y más aún los reconocemos, y entendemos ese tipo de situaciones y la transparencia y honestidad reinará. Aunque la franqueza tiene su lado negativo, generalmente goza de aceptación y “redención”.